Ich dachte, worüber wir heute sprechen, ähnelt dem Programmieren, nur dass wir uns nicht nur darauf konzentrieren, unser Programm korrekt zum Laufen zu bringen, sondern vielmehr darauf, es für Menschen lesbar zu machen und nicht nur für den Computer. Und sind das dann so sehr viele Kommentare und ähnliches? Macht ihr es alle zu wortreich? Wie, was, wie macht man das? Wir könnten unzählige Kommentare haben, aber das Problem bei unzähligen Kommentaren ist, dass sie schnell nicht mehr mit dem übereinstimmen, was der Code selbst tut, und es ist ja eigentlich nicht mehr dasselbe, oder? Dann gibt es zwei Teile: einen für Kommentare für Menschen und einen für den Code für den Computer. Das ist, als würde man überall Haftnotizen hinkleben , nicht wahr? Also, jemand kommt zurück und sagt: „Ach ja, das ist … Wissen Sie, wie das ist? Der Haftzettel ist falsch, aber jeder weiß, dass der Haftzettel falsch ist, und man muss stattdessen tatsächlich diese Sache so machen.“ Der Grund, warum ich darüber nachgedacht habe, ist folgender: Wenn man Softwareentwickler ist, baut man normalerweise etwas für jemanden, und dieser Kunde hat eine Reihe von Anforderungen, die er erfüllen muss , und er kennt sich damit auch bestens aus, aber er kennt sich wahrscheinlich nicht mit Computerprogrammierung aus. Und wenn Sie der Softwareentwickler sind, kennen Sie sich hoffentlich mit Computerprogrammierung aus, aber natürlich werden Sie nicht die genauen Details ihres Geschäfts oder dessen, was sie betreiben, verstehen. Wir brauchen also eine gute Zusammenarbeit, und es wäre hilfreich, wenn wir etwas fänden, worüber wir gemeinsam sprechen könnten, sodass wir sagen könnten: „Ja, wissen Sie, das machen wir jetzt so, und das ist richtig, und das ist falsch.“ Und so schrieb üblicherweise jemand ein großes Dokument, gab es einem Programmierer, der es las, es dann aber auch ein wenig interpretierte und es anschließend in der entsprechenden Programmiersprache kodierte. Und die einzige Möglichkeit, wirklich zu überprüfen, ob das System, das man kennt, richtig verstanden wurde, besteht darin, die Anwendung auszuführen, sie auszuprobieren und dann festzustellen : „Oh, nun ja, in diesem speziellen Fall funktioniert sie nicht ganz richtig. Also, irgendetwas stimmt nicht.“ Zu welchem ​​Zeitpunkt sind seitdem Monate vergangen? Ja, genau. Es wäre also schön, wenn wir stattdessen eine Möglichkeit hätten, bei der sich die Leute zusammensetzen und den Code tatsächlich ansehen könnten und sagen: „Okay, ist das richtig? Oder ist das so? Oh, vielleicht sollten wir es so ändern.“ Aber natürlich verwenden wir Programmiersprachen üblicherweise so, dass es sich um gängige Sprachen handelt, die darauf ausgelegt sind, alle Probleme zu lösen, aber nicht speziell auf bestimmte Probleme zugeschnitten sind. Es gibt also eine Klasse von Dingen, die man domänenspezifische Sprachen nennt, mit denen wir maßgeschneiderte Programmiersprachen entwickeln können, die für bestimmte Probleme geeignet sind. Aber es ist eine Menge Arbeit, so etwas zu bauen . Man kann sich vorstellen, dass die Entwicklung einer Programmiersprache keine triviale Aufgabe ist. Man kann also nicht davon ausgehen, dass jeder Softwareentwickler das ständig tut . Ich dachte, wir könnten uns heute ansehen, ob wir eine gängige Programmiersprache nehmen und, wenn wir schon an die Programmierung denken, die Lesbarkeit für Menschen in den Vordergrund stellen können. Wir wollen sehen, ob wir den Code so gestalten können, dass ihn jemand, der kein Programmierer ist, lesen und vielleicht nicht selbst schreiben kann, aber zumindest bestätigen kann: „Ja, genau das habe ich gemeint.“ oder „Nein, das ist falsch, und wir sollten das so ändern.“ Ich dachte, wir könnten etwas zum Thema Kartenspiele machen, und Sie können sich vorstellen, dass ich vielleicht, wissen Sie, ein Kartenspiel hätte. Ich werde es neu mischen und wir wollen bestimmte Dinge damit machen. Wir könnten also nach allen Pik-Symbolen suchen oder nach allen Symbolen, deren Wert größer als fünf ist, oder nach allen Pik-Symbolen, die größer als fünf sind, und dann könnten wir sie zum Beispiel ausdrucken oder etwas anderes damit machen. Es gibt eine Vielzahl von Möglichkeiten, und wenn man beispielsweise… nun ja, das ist jetzt kein wirklich praktisches Beispiel, aber man könnte sich vorstellen, dass man eine Reihe von Dingen tun möchte . Ich schreibe vielleicht gerade das Programm, um das zu versuchen, und möchte dann bei Ihnen nachfragen: „Oh, ist das so, wie Sie es wollten? Oder wollten Sie etwas anderes? Okay, ändern wir es einfach.“ und damit wir über diesen Codeabschnitt sprechen können. Eine gängige Programmiersprache auszuwählen, die dafür definitiv nicht geeignet ist. Wir programmieren etwas in Java. Es ist ziemlich weit verbreitet. Das schreiben viele Menschen auf der Welt. Nicht besonders schick, in keiner Hinsicht. Ähm, also, was ich bisher geschrieben habe – falls die Leute es auf dem Bildschirm sehen können – ist Folgendes: Ich habe etwas erstellt, das eine Karte darstellen soll, und etwas, das eine Kartenfarbe darstellen soll. Ich öffne das mal, um es Ihnen zu zeigen, und zwar so, dass es ein komplettes Kartenset darstellt, bei dem wir sagen können: Das ist ein vollständiges Kartenset. Wir müssen hier eigentlich nicht mehr nachsehen, aber das sind eben die grundlegenden Dinge, mit denen wir arbeiten werden. Das Programm, das ich bisher geschrieben habe, sagt also einfach: Erstelle ein komplettes Kartenspiel und mische es anschließend. Und das war einfach die Nutzung der in der Sprache integrierten Mischfunktionen. Es gibt also nichts Besonderes, was wir hier getan haben. Und dann möchte ich vielleicht eines dieser Szenarien, über die wir gerade gesprochen haben, aufschreiben, so nach dem Motto: Mal sehen. Nehmen wir also an, wir wollten … Ich schreibe es einfach als Kommentar, wie in einem englischen Satz. Okay . Wie wäre es, wenn wir alle Pik-Karten mit einem Wert unter fünf finden und ausdrucken? Wissen Sie, das könnte eine Anweisung sein, die Sie mir geben könnten, in das Programm einzugeben. Ich könnte also einen Code schreiben, der das tut, aber es wäre schwierig für Sie zu sagen: „Ja, das stimmt.“ Und deshalb möchten wir, dass der Code genau so aussieht. Vielleicht nicht ganz genau so, aber so nah wie möglich dran, und ich denke, das ist etwas, was wir beim Programmieren oft nicht als primären Aspekt betrachten. Wir übertragen das gewissermaßen auf die Sprache der Programmierung, wie z. B. while-Schleifen und Wenn-wenn-das-dann-tue-das. All diese Dinge. Und ich frage mich, ob wir etwas herstellen können, das so aussieht . Also, ich werde versuchen, den Code so zu schreiben. Das wird nicht funktionieren, aber versuchen wir einfach, die richtige Form zu finden und dann zu sehen, ob wir es zum Laufen bringen können. Okay. Vielleicht hätten wir in Java Funktionen, also könnten wir eine Funktion ausprobieren, die alle Karten findet – das ist etwas, was wir bereits im Programm haben. Vielleicht könnte ich also sagen, dass wir das an diese Funktion übergeben könnten. Und dann kommt das, was als nächstes kommt, und man sagt, das seien Pik. Und dann kann ich mir tatsächlich vorstellen, dass die Pik-Einstellung etwas sein könnte, das wir hier ändern möchten. Man könnte sich also vorstellen, dass wir etwas anderes tun wollen, nämlich alle Karten zu finden, die Karo-Karten sind. Vielleicht ist das also etwas, wo wir die Möglichkeit haben sollten, hier eine Option zu übergeben. Vielleicht setze ich das in Klammern, um anzudeuten, dass wir hier eine Funktion haben könnten, der man etwas anderes übergeben könnte. Und wir möchten auch sagen, dass es weniger als fünf ist. Wiederum fühlt sich fünf wie eine Sache an, die ein bisschen… Manchmal möchte man vielleicht weniger als sechs oder ja sagen. Genau. Versuchen wir es also mit weniger als fünf. Und diese beiden, Pik und Kleiner als, wirken wie Auswahlkriterien oder so etwas in der Art . Es handelt sich also im Grunde um ähnliche Dinge. Also, ich habe sie in beiden Fällen an diese weitergegeben . Und was wollen wir dann tun, wenn wir sie gefunden haben? Und dann sagen wir, äh und Und nochmal, wir wollten sie drucken, aber ich kann mir vorstellen, dass wir noch andere Dinge tun wollen . Nehmen wir also an, wir werden sie ausdrucken. Und weil es Java ist, muss ich am Ende ein Semikolon setzen. Hier ist also mein Code, so wie ich ihn mir wünsche – ich wünschte, er würde existieren. Wir müssen es einfach dafür schaffen . Und so, weil wir mit dieser Herangehensweise begonnen haben, um zu sagen: Nicht wie der Code am Ende aussehen wird, sondern wie ich ihn haben möchte. Und nun verändern wir die Programmiersprache, um genau das zu erreichen. Was genau sind also definierte Funktionen, die diese Eigenschaften besitzen? Rechts. Ja . Anstatt also zu sagen: „Welche Funktionen habe ich?“ und dann mein Programm aufzubauen, möchte ich lieber damit beginnen: „ Wie soll es sich lesen lassen, sodass wir uns darauf einigen können?“ Und an diesem Punkt könnte man sogar sagen, dass das falsch ist. Und selbst wenn es noch nicht funktioniert, könnte man trotzdem sagen: „Oh nein, nicht Pik.“ Rechts? Ja . Oder so ähnlich. Und so könnten wir es an diesem Punkt beheben. Und dann können wir es so machen, sobald wir wissen, dass es richtig ist. Die etwas knifflige Frage ist also, ob es überhaupt funktioniert. Äh, also, wir können ein paar Dinge definieren. Rechts? Eines der Dinge, die ich hier mit IntelliJ für meinen Java-Code verwende, ist, dass es mir in Rot mitteilt, dass einige Dinge nicht existieren. Also, wir könnten die herstellen. Also, das ist zunächst einmal eine kleine Beschwerde über diese „ weniger als“-Sache. Also, lasst uns zunächst eine Funktion erstellen, die kleiner als ist, und einfach dafür sorgen, dass sie nicht mehr ständig meckert . Also, „kleiner als“ ist eine Funktion, die eine Zahl entgegennimmt und äh, nun ja, ich weiß noch nicht genau, was sie tut, aber zumindest habe ich aufgehört, mich darüber zu beschweren. Und dann gibt es da noch Spades. Lasst uns zuerst die Reihenfolge herausfinden. Das heißt, die Funktion „find order“ benötigt eine Liste von Karten, die wir bereits im Programm haben. Und es wird etwas bewirken, aber ich bin mir noch nicht sicher. Äh, und ich muss es sagen: Oh nein, es ist eine Kartenliste. So, jetzt haben wir's. Es wird also etwas besser. Wir haben noch ein paar rote Sachen. Äh, also, wir haben etwas, das Pik-Symbole sind, und wir haben etwas, das sie ausdruckt. Also, wir sprachen darüber, dass es so etwas wie ein Kriterium, eine Auswahl, eine Einschränkung oder so etwas sein könnte. Welche davon fühlt sich am besten an? Nun ja, es ist ja eine Option, nicht wahr? Von den vier verschiedenen möglichen Anzügen. Es ist also etwas, das man selbst auswählen möchte. Ja, eine Wahl. Eine Wahl. Nun gut , dann war's das. Nehmen wir also an, wir erfinden etwas namens „Wahlmöglichkeit“ und nehmen es in das Programm auf, denn wir haben uns darauf geeinigt, dass dies der Begriff ist, der am sinnvollsten erscheint . Also, das ist das englische Wort dafür. Ja, okay. Also, äh, wir werden etwas erstellen, ich werde eine Schnittstelle erstellen, die einfach so etwas wie „Dies wird die Auswahl definieren“ besagt, aber wir werden noch nicht wirklich viel darüber sagen, aber es wird etwas sein, das in der Sprache vorhanden ist. Bislang wollen wir nicht mehr sagen, als dass es existiert und Pik dann eine Option sein kann. Ich habe also die Wahl zwischen zwei Pik-Figuren. Und dann wird es nicht rot. Und dann drucke sie aus. In ähnlicher Weise empfinde ich das Ausdrucken als eine Handlung, die wir vielleicht ausführen möchten, nachdem wir unsere Auswahl getroffen haben. Also, lasst uns etwas erschaffen. Lasst uns dasselbe tun. Lasst uns eine Schnittstelle namens „Aktion“ erstellen. Und ich werde eine Aktion namens „ Drucken“ erstellen. Und dann haben wir es fast geschafft. Wir müssen nur diese Funktion so aufrufen, dass sie lautet: Diese Aufgabe ist etwas komplizierter, da wir in Java arbeiten. Es handelt sich um eine objektorientierte Sprache. Dies, das sind, kommt nach einem Punkt. Es handelt sich also um eine Methode eines Objekts. Was wir bisher noch nicht besprochen haben, aber als ich es ursprünglich aufgeschrieben habe, wissen Sie, habe ich es in einem englischen Satz geschrieben, von links nach rechts. Und dann haben wir eine Codezeile geschrieben, die ein bisschen komisch aussah, weil sie ziemlich lang ist. Es handelt sich nicht um eine Reihe von Aussagen, die besagen: Zuerst tu dies, dann tu jenes, tu jenes. Das ist also das, was wir als flüssiges Design, als flüssiges API-Design bezeichnen würden. Das bedeutet also, dass wir versuchen, es so zu schreiben, als wäre es ein Satz, aber wir müssen ein paar kleine Anpassungen vornehmen, damit es trotzdem richtig ausgeführt wird. Wir brauchen also etwas, das alle Karten findet und uns zu dem zurückführt, wo wir etwas tun können, das man als Verfeinerung oder Ähnliches bezeichnet. Das war's also fast . Ja, also es wird entweder etwas sein, das man filtern kann, oder ich dachte eher an eine Art Auswahl oder so etwas in der Art. Vielleicht müssen wir also alle Karten finden, um eine Auswahl zurückgeben zu können. Vielleicht handelt es sich um eine Auswahl? Es ist so ziemlich das Einzige, was man auswählen kann. Oh, das ist so eine Art „Ja, nun, nun“-Liste. Ich denke, ja, aber es könnte etwas konzeptioneller sein. Okay. Weil ich denke, dass eine Liste etwas mit Programmierung zu tun hat . Okay, also ein Ja, nun ja , so ein „ Ja“, weil mir das Wort nicht einfällt. Mir fällt es nicht ein. Ja, also das ist ein interessanter Punkt: Während wir es gemeinsam entwickelten, fragten wir uns immer wieder: „Wie nennt man das?“ Und so versuche ich nur, ein bisschen mehr herauszukitzeln. eine gemeinsame Terminologie. Damit wir in Zukunft über diese Dinge sprechen können. Ich würde sagen: „Oh ja, genau das ist es.“ Jetzt aber zu Option, Optionen. Ähm, ich stelle mir vor, dass ein großer Konzern eine große Besprechung zu diesem Thema abhält. Was ist es wert? Ja, es ist viel Whiteboard und viel Stifte. Stifte und Menschen kommen heraus. Ja ja . Was, wie ich finde, in manchen Fällen hilfreich sein kann. Ähm , also, nehmen wir mal eine Auswahl. Das stimmt so nicht ganz. Wir könnten es später noch verfeinern. Aber ich werde mich für die Auswahl entscheiden. Zusammenfassend lässt sich sagen, dass die Methode „Alle finden“ eine Auswahl zurückgibt. Rechts. Das bedeutet, dass wir all dies mit der Auswahl tun können, um sie zu verfeinern. Also, ich werde das erstellen. Nicht umbenennen. Machen wir das. Das alles ist also eine Methode der Selektion. Also , sagen wir mal, das ist alles, und es dauert… Nun haben wir zwei Möglichkeiten. Man könnte also sagen, dass es eine Reihe von Entscheidungen erfordert. Und darüber beschwert es sich. Warum beschwert es sich über die Wahlmöglichkeiten? Nein, ich glaube, das ist… Oh ja, nun, das ist ein Problem. Es beschwert sich hier, weil wir beim letzten Mal gesagt haben, dass es sich um eine Funktion handelte, die void zurückgab. Ich habe nichts zurückgegeben. Aber eigentlich wollen wir, dass es eine Entscheidung trifft. Wir wollen, dass es eine Wahlmöglichkeit ist. Sagen wir also Folgendes: Und wir sind jetzt schon ziemlich nah dran. So, jetzt können wir sagen: „Okay, und ist eine weitere Methode. Das sollte eine Methode für den Rückgabewert von R sein, [schnaubt] was wir gleich herausfinden können. Ähm, R gibt im Moment void zurück. Also wird es zurückgeben. Machen wir eine kleinere Auswahl. Du hast also mit einer Auswahl von Karten angefangen. Du hast sie etwas verfeinert und hast jetzt eine kleinere Auswahl. Also, eine weitere Auswahl, ja, okay. Und ähm, dann können wir sagen: Sobald du eine Auswahl hast, kannst du Dinge damit machen.“ Und das, was hier vielleicht etwas ungewöhnlich ist, ist, dass wir in der Programmierung normalerweise, wenn wir ein Wort wie „und“ verwenden, sehr darauf achten würden, es logisch zu verknüpfen. Aber wir haben den Satz so geschrieben: Wähle diese Dinge aus und gib sie aus. Also eine Art Sequenzierung. Es ist effektiv: Mach das damit, nicht wahr? Also, würdest du lieber „ dann“ sagen? Würde das Sinn ergeben? Nun , vielleicht, vielleicht würde das Sinn ergeben, ja, ja. Also, wir könnten das ändern. Also, das ist Okay. Also, dann drucken wir sie aus. Und nochmal , um sicherzugehen, dass wir alles richtig verstanden haben. Dann erstelle ich eine Methode namens `then`, die auf Auswahlen angewendet wird. Sie erledigt das für uns. Ja, los geht's . Erstellen wir also eine Methode, mit der man Aktionen auf Auswahlen anwenden kann. Man kann Auswahlen Aktionen zuweisen. Solange eine Aktion vorhanden ist, kann man sagen: „Okay, dann führe diese Aktion aus.“ Bisher haben wir es noch nicht zum Laufen gebracht . Aber fangen wir zumindest an und versuchen wir, es zum Laufen zu bringen, um zu beweisen, dass wir nicht nur herumexperimentieren, sondern dass wir es tatsächlich zum Laufen bringen können. Ich könnte jetzt versuchen, es auszuführen . Natürlich wird es nicht funktionieren, aber es hilft uns, die Fehlerquellen zu finden. Also, äh, ich Ich kann mein Programm ausführen. Also, versuchen wir es. Okay, und es gibt eine Fehlermeldung, dass in Zeile 21 ein Nullwert vorliegt. Was ist das? Okay, irgendwo in unserer langen Codezeile ist der Fehler aufgetreten, weil der Wert null war. Ich denke, das Problem ist, dass die Funktion „Alle Karten finden“ einen Nullwert zurückgibt. Wir rufen also „Alle Karten finden“ auf, und die Fehlermeldung lautet: „Ja, okay, hier ist ein Nullwert.“ Wenn man dann versucht, damit etwas anderes zu machen, stürzt das Programm sofort ab. Genau . Man kann sich also die Codezeilen durcharbeiten und den gesamten Code – vielleicht ist das nicht der richtige Ausdruck – in den Backend-Bereich auslagern, den die Person, mit der man zusammen sitzt, nicht kennen muss. Richtig. Sie kann aber sehen, was der Code tun soll . Und wenn das erste Problem behoben ist, können wir wieder zur obersten Ebene zurückkehren. und sagen: "Okay, jetzt willst du noch eine machen, die sich um Diamanten dreht." „Also, jetzt wollen Sie das machen. Oh, jetzt haben Sie Dinge, die kleiner als acht und größer als drei sind und Pik darstellen.“ An diesem Punkt könnten wir hoffentlich weitermachen, ohne weitere dieser grundlegenden Programmierstrukturen schreiben zu müssen. Ja. Wir hätten vielleicht ein oder zwei Stunden damit verbracht, diese grundlegenden Strukturen zusammenzustellen, aber gleichzeitig quasi unsere eigene Programmiersprache entwickelt, mit der wir über – in diesem Fall Kartenauswahlen, aber in anderen Fällen Studentendatensätze, Einzelhandelstransaktionen, Versicherungstarife oder was auch immer – sprechen können, und zwar mit der Terminologie, auf die wir uns geeinigt haben und die für uns beide verständlich ist. Ja. So verwende ich keine Programmierbegriffe, und Sie sprechen in Geschäftssprache, und wir könnten leicht ein Missverständnis haben, wenn ich denke, ein bestimmtes Wort bedeutet etwas anderes, als Sie . Auf diese Weise erreichen wir, dass das Programm zumindest auf dieser Ebene alle Wörter verwendet. Aus unserem vereinbarten gemeinsamen Vokabular, das keine Programmierbegriffe verwendet . Ich denke, wenn wir diesen Punkt erreichen und diesen Ansatz konsequent verfolgen, können wir immer mehr Code auf einem Niveau entwickeln, auf dem wir darüber sprechen können . Darunter befindet sich dann eine Ebene, über die wir nicht gemeinsam sprechen, da diese die Verkabelung und die Infrastruktur umfasst, die wir für die Funktionsfähigkeit benötigen. Stellen Sie sich vor, jemand möchte ein Haus bauen lassen und wünscht sich eine Steckdose. Er muss nicht wissen, wie die Kabel dorthin verlegt wurden, sondern nur die Steckdose . Ist es so ähnlich? Ich denke, er könnte beispielsweise darüber sprechen, ob er einen zwei- oder dreipoligen Stecker, ein USB-C-Ladegerät oder Ähnliches benötigt. Wie das hinter dem Verteilerkasten funktioniert, ist nicht wichtig. Wichtig ist nur, dass man sich in diesem Fall mit dem Elektriker über ein bestimmtes, vereinbartes Vokabular verständigen kann. Es geht darum, die verschiedenen Aspekte abzuwägen, damit man das gewünschte Ergebnis erzielt. Es scheint, als würde viel Aufwand betrieben, um die Kommunikation über diesen Code zu gewährleisten. Lohnt sich das wirklich? Sollte ich Ihnen einfach eine Spezifikation geben, sagen, ich brauche den Code für dies und das, und in einem Monat wiederkommen und hoffen, dass er funktioniert? Ich denke, es ist schwer zu sagen, ob sich der Aufwand immer lohnt . Wie Sie richtig sagen, mussten wir einiges an Arbeit in die Entwicklung investieren, aber hoffentlich wäre es sinnvoll, wenn es sich um einen Bereich handeln würde, in dem wir häufig arbeiten. Wenn wir also in einem Unternehmen arbeiten und viele Funktionen für Handelsstrategien oder Ähnliches entwickeln würden, müssten wir solche Änderungen ständig vornehmen. Und eine elegante Sprache zu haben, um diese schnell und einfach auszudrücken, wäre von Vorteil. Wenn wir nur eine einmalige Sache entwickeln würden, etwas völlig anderes als alles andere im System, wäre der Aufwand vielleicht nicht so groß. Aber ich denke, wenn es etwas im Kern gibt, das Wir werden an vielem arbeiten, und ich denke, es kann sich lohnen . Du scheinst dich deutlich mehr anzustrengen als ich. Ich glaube fast, du passt das Ganze an meine Bedürfnisse an, und ich denke, das stimmt im Moment. Aber wenn wir in einer Woche zurückkämen und du sagtest: „Oh, es gibt da eine neue Funktion, und wir müssen etwas mit bestimmten Kartenkombinationen machen“, und wir dann sagen würden: „Okay.“ Nun ja, eigentlich haben wir einen Großteil der sprachlichen Dinge bereits letzte Woche definiert. Hoffentlich müssen wir das also nicht noch einmal durchmachen . Wir haben uns sozusagen eine eigene Sprache geschaffen, die unser Problem sehr gut beschreibt. Und hoffentlich geht das Schreiben der neuen Teile sogar noch schneller, als wenn wir sie alle von Hand in den Code schreiben würden. Es erfordert also vielleicht etwas Vorarbeit, aber ich denke, dass wir durch die Diskussion über die Entdeckung der Terminologie und die Bedeutung der Konzepte und darüber, was diese Dinge wirklich sind, wertvolle Erkenntnisse gewonnen haben, insbesondere im Hinblick auf den Versuch, das Ganze überhaupt erst aufzubauen . Nutzt das wirklich irgendjemand? Macht das irgendjemand ? Ich glaube, es gibt eine kleine Gruppe von Leuten, die das in ihrem Implementierungscode tun . Entwickler sprachen immer davon, sauberen Code zu schreiben. Ich denke, so etwas wie lesbarer Code. Ich glaube, das geht noch einen Schritt weiter. Aber ich denke, seine Stärken kommen erst richtig zum Tragen, wenn man Tests schreibt, um die eigene Software zu testen. Heutzutage schreiben wir typischerweise eine ganze Reihe von Tests, um sicherzustellen, dass unsere Software korrekt ist. Wenn Ihr Test sehr verständlich ist und von der Person, die das System haben wollte, bestätigt werden kann, sodass diese sagen kann: „Dieser Test ist korrekt und wurde bestanden.“ Stellen Sie sicher, dass Ihre Software korrekt ist. Wenn ein Test bestanden wird, aber niemand genau versteht, was er bedeutet, kann man kaum Vertrauen darin haben . Wenn wir also diese Anstrengungen unternehmen, um Tests zu erstellen, die validiert werden können, indem ich Ihnen den Test zeige, den wir für das System geschrieben haben, und Sie sagen: „Das ist der richtige Test.“ Oder, genauer gesagt, in diesem Fall ist das nicht ganz korrekt, es sollte so sein, und dann führen wir diesen Test durch, und wenn dieser Test erfolgreich ist, dann bin ich zuversichtlich, dass wir das Richtige für Sie entwickeln. Und gibt es dazu vielleicht noch eine letzte Frage ? Offensichtlich haben Sie das in dieser speziellen Sprache in Java gemacht. Ist sie portabel oder ist das dasselbe Problem wie bei jedem anderen Code, den Sie portieren müssen? Die kleine Sprache, die wir entwickelt haben, ist nicht portabel. Und wenn wir das Gleiche in Python, JavaScript oder C# machen könnten, würden wir zwar etwas andere Tricks und Techniken verwenden, um die Sprache zu gestalten, aber ich denke, man könnte dieselbe Philosophie verfolgen: Ich versuche, den Code so zu schreiben, dass zumindest die Problembeschreibung auf oberster Ebene sehr verständlich ist , und lasst uns die Merkmale der jeweiligen Sprache nutzen, um dies zu erreichen, anstatt alles von Grund auf neu aufzubauen und zu sagen: „So drücke ich das Problem in meiner Sprache aus, und so sieht es aus .“ Mir gefällt es also viel besser, von dem aus ich das gewünschte Aussehen entwickle, anstatt es Schritt für Schritt aufzubauen und dann so zu gestalten. Ein mögliches Interleaving wäre beispielsweise, dass ich zuerst die Rechtsoperation auf X ausführe, also diese hier, und dann die Rechtsoperation auf Y. Die beiden Rechtsoperationen werden also ausgeführt, bevor ich mit den beiden Leseoperationen fortfahre. Als Ergebnis werden beide Lesevorgänge den aktualisierten Wert beobachten und beide den Wert eins lesen. Also, ich kann eins lesen. Eine weitere mögliche Verschachtelung ist

Ich dachte, wir könnten heute über randomisiertes Testen, auch Fuzzing genannt, sprechen. Das ist eine wirklich effektive Technik, um Fehler in Software zu finden. Wo genau das Fuzzing seinen Ursprung hat, ist tatsächlich etwas umstritten. Das ist eine dieser Techniken, die ziemlich offensichtlich sind. Man hat also eine Software, und wenn wir als Programmierer Software entwerfen, denken wir normalerweise darüber nach, was die Software leisten soll , wie die Leute sie benutzen sollen und welche Fehler sie dabei natürlicherweise machen würden. Wir denken nicht oft über absolut verrückte Möglichkeiten nach, die Software einzusetzen. Wenn Sie beispielsweise eine Textverarbeitungsanwendung hätten , würden Sie über das Layout nachdenken, über die Funktionen, die sie unterstützen sollte, und über Dinge wie den Fall, dass der Benutzer versucht, eine nicht existierende Datei zu öffnen. Aber man denkt vielleicht nicht unbedingt an Fälle, in denen sie ein Dokument erstellen, in das sie alle möglichen verrückten Inhalte einfügen, oder man denkt vielleicht nicht daran, dass sie beispielsweise versuchen, eine Videodatei mit dem Textverarbeitungsprogramm zu öffnen, und was dann passieren würde. Softwarefehler treten häufig aufgrund unerwarteter Eingaben auf, an die der Programmierer nicht gedacht hat. Randomisierte Tests sind eine hervorragende Methode, um solche unerwarteten Eingaben zu finden. Fuzzing ist im Internetzeitalter immer wichtiger geworden, denn wenn man an Systeme wie Webbrowser wie Chrome, Safari und Firefox denkt, die von Milliarden von Nutzern weltweit verwendet werden, handelt es sich um völlig offene Systeme. Bei einem Phishing-Angriff, bei dem man jemanden dazu verleitet, auf eine Webseite zu klicken, die ihn dann auf eine zufällige, bösartige Webseite weiterleitet, kann diese Webseite beliebigen Inhalt haben. Daher muss der Webbrowser auch gegenüber völlig beliebigem HTML robust sein. Es muss nicht unbedingt etwas Sinnvolles für das HTML gerendert werden, aber es darf nicht der Fall sein, dass zufälliges HTML oder JavaScript eine Sicherheitslücke im Webbrowser aufdeckt. Und angesichts der jüngsten Nachrichten über Dinge wie Claude Mythos, Sie wissen schon, das große Sprachmodell, über das es einige Bedenken gibt, wenn von Sicherheitslücken die Rede ist, geht es um Dinge wie Eingaben, die dazu führen könnten, dass sich ein offenes System wie ein Webbrowser nicht nur falsch verhält, sondern tatsächlich den Einstiegspunkt für beispielsweise einen Remote-Execution- Angriff bietet. Das ist genau die Art von Dingen, die den Leuten Sorgen bereiten . Und Fuzzing ist eine wirklich gute Methode, um sich gegen solche Probleme zu verteidigen, denn durch das Testen eines Systems mit zufälligen Eingaben kann man möglicherweise zufällig auf einige dieser Hintertüren stoßen. Es gibt im Grunde zwei Extreme, was die Leute mit Fuzzing erreichen wollen. Im einen Extremfall möchte man Software stichprobenartig mit verstümmelten, bösartigen Eingaben testen, die eigentlich nicht in die Software gelangen sollten, mit dem Ziel, Schwachstellen in der Software zu finden. Am anderen Ende des Spektrums möchte man die Software vielleicht mit sehr sorgfältig ausgearbeiteten, wohlgeformten, aber extrem komplizierten Eingaben testen und tatsächlich herausfinden, ob die Software bei solchen Eingaben das Richtige getan hat. Und die Forscher sind an fortschrittlichen Techniken an beiden Enden des Spektrums interessiert. Vielleicht beginne ich damit, über die verschiedenen Möglichkeiten zu sprechen, wie man Fuzzing, auch bekannt als randomisiertes Testen, zum Testen komplexer Systeme einsetzen kann, um sicherzustellen, dass sie tatsächlich korrekt funktionieren . Ein wirklich gutes Beispiel hierfür sind Compiler. Compiler wie GCC oder Clang für C oder Java C für Java. Und es gibt sehr viele Programmiersprachen mit oft mehreren Compilern pro Sprache. Und ein Compiler kann, wie jedes Programm, abstürzen, wenn man ihm eine erwartete oder unerwartete Eingabe gibt. Möglicherweise liegt ein Fehler vor, der schlichtweg zum Absturz des Compilers führt . Bei einem Compiler gibt es jedoch eine noch schlimmere Art von Fehler, die als Fehlkompilierung bekannt ist. Dabei übergibt man dem Compiler Quellcode, und der Compiler wandelt diesen ohne Beanstandung in Binärcode um. Es wandelt den Code in ausführbaren Objektcode um und gibt dabei keinen Hinweis darauf, dass etwas schiefgelaufen ist. Die Übersetzung des Quellcodes in den ausführbaren Binärcode hat jedoch die Bedeutung des Programms nicht korrekt wiedergegeben. Die Semantik des Quellprogramms wurde nicht beachtet. Um ein unrealistisch einfaches Beispiel zu nennen: Wenn das Programm x + y ausgibt und der Compiler dies in eine Multiplikationsanweisung übersetzt, die x mit y multipliziert, dann wäre das eine Fehlkompilierung. Wir hoffen natürlich, dass einem Compiler niemals ein so drastischer Fehler unterläuft, aber Compiler führen bei der Übersetzung von Quellcode in Assembler wirklich ausgeklügelte Optimierungen durch, und diese Optimierungen können Randfälle aufweisen, an die der Compiler-Entwickler nicht gedacht hat, und sie funktionieren möglicherweise nicht in allen Umgebungen. Sie sollten, aber vielleicht tun sie es nicht. Ein wirklich interessanter Arbeitszweig, bei dem Fuzzing zum Testen von Compilern eingesetzt wird, besteht darin, einen Fuzzer zu erstellen, einen Zufallsgenerator, der zufällig Programme in einer gegebenen Programmiersprache erzeugt, die eigentlich wohlgeformte Programme sein sollten. Sie würden nichts Sinnvolles tun, sondern lediglich die Besonderheiten der Sprache auf alle möglichen seltsamen und wunderbaren Arten nutzen. Sie sollen nicht etwa keinen gewünschten Effekt erzielen, sondern lediglich sicherstellen, dass beim Ausführen eines dieser zufällig generierten Programme eine Ausgabe entsteht. Vielleicht würde es einfach eine ganze Zahl ausgeben. Welche ganze Zahl das wäre, hinge vollständig von der zufälligen Struktur des Programms ab. Die Herausforderung besteht jedoch darin, Programme zu generieren, die bei ihrer Ausführung ein deterministisches ganzzahliges Ergebnis liefern. Dann können Sie beispielsweise, wenn Sie zwei Compiler zu testen haben, sagen wir der Einfachheit halber GCC, den GNU C- Compiler, und Clang, einen weiteren sehr bekannten Open-Source-Compiler für C und C++ . Wenn Sie einen Fuzzer haben, also eine Software, die Programme generiert, dann wird der Fuzzer ein Programm generieren. Der Inhalt dieses Programms wird also vom Fuzzer zufällig bestimmt. Das Programm wird jedoch ein vollständig deterministisches Programm sein. Wir können dieses Programm an GCC oder Clang übergeben, und diese kompilieren es dann zu ausführbaren Dateien. Nennen wir sie also 1.exe und 2.exe. Wenn wir nun diese ausführbaren Dateien mit derselben Eingabe ausführen, sagen wir, wir geben ihnen eine Eingabe I und geben ihnen beiden dieselbe Eingabe I, dann liefert uns dieses Programm eine Ausgabe O1. Und dieses Programm liefert uns einen Ausgang O2. Dann sollten diese Ausgaben gleich sein. Der Fuzzer hat ein Programm generiert. Wir haben dieses Programm beiden Compilern übergeben. Wir haben das Programm kompiliert, um zwei ausführbare Dateien zu erhalten. Diese ausführbaren Dateien könnten sich stark voneinander unterscheiden, da die Compiler möglicherweise unterschiedliche Entscheidungen hinsichtlich der Codeoptimierung getroffen haben. Sie werden also unterschiedliche Methoden zur Erzeugung einer Binärdarstellung des Quellcodes verwenden, aber diese Binärdarstellungen sollten dasselbe kodieren. Beide sollten die Semantik dieses Programms kodieren. Wenn wir sie dann mit der gleichen Eingabe ausführen, sollten wir erwarten, die gleiche Ausgabe zu erhalten. Und wenn das nicht der Fall ist, deutet das darauf hin, dass bei der Kompilierung etwas schiefgelaufen ist . Irgendwo in einem dieser Compiler muss ein Fehler vorliegen. Hierbei sind jedoch einige wichtige Einschränkungen zu beachten. Für Ihre Zuschauer, die sich mit C und C++ auskennen: Diese Sprachen sind voller undefiniertem Verhalten. Und wenn dieses Programm undefiniertem Verhalten unterliegt, könnte es sein, dass diese ausführbaren Dateien aufgrund des undefinierten Verhaltens tatsächlich unterschiedliche Ergebnisse liefern. Die eigentliche Herausforderung besteht also darin, sicherzustellen, dass es in diesem Programm kein undefiniertes Verhalten, kein UB gibt . Ist das dann ein Beispiel für undefiniertes Verhalten? In C ist ein Beispiel für undefiniertes Verhalten die Division durch Null. Okay. Das führt also häufig zum Absturz des Programms , aber das ist nicht garantiert. Der Programmcode besagt nicht, dass eine Division durch Null zum Absturz des Programms führt. Es ist tatsächlich undefiniert. Ein weiteres Beispiel ist das Lesen aus einem Array außerhalb seiner Grenzen, also ein Array- Überlauf oder ein Array-Unterlauf. Und es gibt tatsächlich eine große Anzahl von Beispielen für undefiniertes Verhalten in der Sprache. Das ist ein Beispiel für randomisiertes Testen im Bereich der Compiler. Und es gibt ein Tool namens Csmith, das ursprünglich von der University of Utah stammt. Also, weil es eine Sammlung von C-Programmen ist. Und Csmith ist der Fuzzer, der diese randomisierten C- Programme erzeugt. Die entscheidende Innovation dieses Csmith-Projekts besteht genau darin, Programme zu entwickeln, die dieses undefinierte Verhalten nicht aufweisen. Okay. Dies ist also ein Beispiel für Fuzzing, um tiefgreifende funktionale Fehler in einem komplizierten Softwareprodukt, einem Compiler, aufzuspüren. Es geht nicht darum, Sicherheitslücken zu finden, bei denen der Compiler abstürzt und eine ausnutzbare Schwachstelle entsteht, wenn man ihm unverständlichen Code zuführt. Das ist nicht der Zweck dieser Unschärfe. Es geht eigentlich darum, tiefgreifende Probleme zu finden, bei denen der Compiler ein Programm tatsächlich falsch optimiert. Das Programm enthält einen echten Fehler. Okay. Und kommt man an einen Punkt, an dem man ein Problem damit kategorisch beweisen kann , oder ist es ein bisschen wie in jeder Wissenschaft, wo man es tausendmal testen kann und alle Tests scheinbar in Ordnung sind, und man deshalb trotzdem nicht beweisen kann, dass es in Ordnung ist, weil der eintausendunderste Test ein Fehler sein könnte? Genau. Generell geht es bei Softwaretests jeglicher Art also darum, das Vorhandensein von Fehlern aufzuzeigen, nicht darum, die Abwesenheit von Fehlern zu beweisen. Man kann also nicht mit Tests nachweisen, dass Software korrekt ist. Man kann es nur verwenden, um zu zeigen, dass die Software fehlerhaft ist. Doch der Prozess, bei dem wiederholt gezeigt wird, dass die Software fehlerhaft ist, diese Fehler behoben werden und es dann immer schwieriger wird, Fehler in der Software zu finden, beweist, dass die Software immer zuverlässiger wird. Ein sehr schwieriges Problem, an dem einige Akademiker interessiert sind – ich finde es interessant, aber es ist nichts, worüber ich mir Sorgen mache –, ist die Frage: Woher weiß man, dass man alle Fehler gefunden hat? Meine praktische Erfahrung aus meiner Zeit in verschiedenen Unternehmen lässt mich vermuten, dass man das nie tut. Man findet nie alle Fehler. Es sei denn, Sie arbeiten an sicherheitskritischer Software mit hohen Anforderungen an die Sicherheit, wo Sie tatsächlich formale Verifikation einsetzen, um die Korrektheit der Software nachzuweisen. Wenn Sie nicht in diesem Bereich arbeiten, dann enthält jede Software Fehler. Ja . Und dann stellt sich die sehr relevante Frage: Welche Fehler sind Ihnen wichtig? Interessieren Sie sich also für all diese Fehler, die Fuzzer finden können? Fuzzer finden also manchmal Probleme, die eigentlich Bugs sind, aber ob jemals jemand auf eine Datei mit einem dieser Bugs stoßen würde, ist fraglich, und das ist an sich schon eine interessante Frage. Das Problem bei all dem ist, dass wir mit den Systemen, die wir heute verwenden, natürlich – ich meine, ich muss da an den XKCD-Comic „ The Nebraska“ denken. Das Nebraska-Modell mit dem winzigen, wissen Sie, man kann sich ansehen, was man da sieht, aber es könnte auf so vielen anderen möglichen Frameworks und Plattformen aufbauen. Das ist richtig. Diese Techniken müssen also unter Berücksichtigung des jeweiligen Kontextes eingesetzt werden. Ich denke, Sie wissen, dass es bei dieser Arbeit an diesen Unix- Dienstprogrammen darum geht, dass diese Dienstprogramme, obwohl einige davon sehr einfache Werkzeuge sind, von einer großen Anzahl von Menschen benutzt werden, ohne dass man wirklich weiß, wofür sie sie verwenden – für alle möglichen Dinge. Es gibt also gute Gründe dafür, sie besonders zuverlässig zu machen. Compiler – wir wissen, dass viele Unternehmen auf Compiler wie GCC und Clang angewiesen sind. Sie gehören zu den besten Beispielen für Open-Source- Projekte, die wir haben. Es gibt also ein sehr starkes Argument dafür, sie so fehlerfrei wie möglich zu gestalten. Aber mal ehrlich, spielt es wirklich eine Rolle, ob GCC abstürzt, wenn man ihm eine Datei voller nicht druckbarer Zeichen gibt? Wenn es nicht kompiliert, wenn es einfach mit einem schwerwiegenden Fehler abstürzt, anstatt beispielsweise einen Syntaxfehler anzuzeigen, spielt das dann wirklich eine Rolle? Ist das ein Fehler, der tatsächlich von Bedeutung ist? Ich würde sagen: Nein. Wissen Sie, selbst bei etwas so Wichtigem wie GCC ist nicht jeder Fehler in GCC von Bedeutung. Und ich möchte über Coverage-Guided Fuzzing sprechen, das durch ein Tool namens AFL ( American Fuzzy Lop) bekannt wurde. Dieses Tool stammt von einem Entwickler bei Google und hat vor einiger Zeit den Weg für eine Vielzahl praktischer Arbeiten und Forschungen im Bereich Fuzzing geebnet. Nehmen wir an, wir haben ein System, das wir testen wollen, SUT, System unter Test. Wenn wir uns die Funktionsweise des Systems wie ein Labyrinth vorstellen, dann gibt es alle möglichen Orte, an die man in diesem System gelangen kann. Wenn Sie dann eine Art zufällige Eingabe an dieses System senden, beispielsweise zufällige Bytes, dann kann es sein, dass diese in Teile der Software gelangen. Und dann wird ein weiterer Eingang ausgelöst, der in einen anderen Teil des Systems gelangt. Und dann gelangt ein weiterer Eingang in einen etwas anderen Teil des Systems. Es könnte aber sein, dass ein Eingabefeld bestimmte Merkmale aufweisen muss, um überhaupt weiter in das System gelangen zu können . Zum Beispiel kann es sein, dass man einem Linux- Dienstprogramm gültige Befehlszeilenargumente übergeben muss, um einen Großteil seines Verhaltens freizuschalten. Bei vielen Dienstprogrammen muss man beim Ausführen zahlreiche Argumente in der Befehlszeile angeben. Und wenn Sie ein bestimmtes Argument angeben, wird die Eingabe auf eine bestimmte Weise behandelt. Es kann also sein, dass Sie ganze Bereiche des Systems nie erreichen werden, es sei denn, Sie liefern das richtige Argument. Dieser Ansatz mag zwar einige pathologische Fälle aufdecken, in denen ein System abstürzt, aber es ist unwahrscheinlich, dass er Eingaben findet, die das System in wirklich tiefgreifende und interessante Zustände versetzen. Eine Technik, die dieses Problem überwindet, ist das sogenannte Coverage Guided Fuzzing. Bekannt wurde es durch ein Tool namens AFL ( American Fuzzy Lop), das vor einiger Zeit von einem Google-Ingenieur entwickelt wurde und zu zahlreichen Folgeprojekten in der Praxis sowie zu vielen akademischen Forschungsarbeiten und verschiedenen anderen Fuzzern wie beispielsweise Googles Libfuzzer geführt hat, der ein Fuzzer im AFL-Stil ist. Wenn wir uns unser zu testendes System noch einmal als labyrinthisch vorstellen, besteht die Idee des Coverage Guided Fuzzing darin, dass wir über einen Korpus von Eingaben verfügen, die während des Testprozesses verwendet werden . Anfangs könnte dieser Korpus einige Beispiele für reale Eingaben für das System enthalten. Wenn es sich bei dem System beispielsweise um eine PDF-Engine handeln würde, könnten wir eine Auswahl an Beispiel-PDFs haben, die bereits eine gewisse Abdeckung des Systems bieten. Die Idee besteht darin, Eingaben zu finden, die tiefer in das System hineinreichen, tiefer in das Labyrinth vorzudringen, in der Hoffnung, Fehler zu finden. Nehmen wir also an, dass sich irgendwo in diesem Labyrinth ein Fehler versteckt. Die Idee ist, dass wir nicht wissen, wo dieser Fehler liegt, aber durch die Erkundung des Labyrinths hoffen wir, einen oder mehrere dieser Fehler zu finden, die behoben werden können, um das System zuverlässiger zu machen. Die Idee des abdeckungsbasierten Fuzzings ist folgende: Angenommen, dieser Korpus enthält eine Reihe von Eingaben, aber anfänglich enthält er vielleicht eine Eingabe A. Und hier meine ich nicht wörtlich das Zeichen A. Ich bezeichne A einfach als die Eingabe. A könnte beispielsweise eine PDF-Datei sein. Der Fuzzer wird dann den Input A aus dem Korpus extrahieren. Und dann wird A zufällig mutiert, um eine mutierte Eingabe zu erhalten. Nennen wir es eine Primzahl. Die Mutationen, die durchgeführt werden, um von einer Eingabe A zu A prime zu gelangen, werden zufällig angewendet und können beispielsweise das Umdrehen eines Bits, das Ersetzen einer Bytefolge durch eine andere Bytefolge, das Löschen einiger Bytes aus der Eingabe oder das Zusammenfügen zweier Eingaben umfassen. Nun wird also diese A-Prime dem zu testenden System zugeführt. Und A Prime wird eine gewisse Abdeckung des Systems erreichen, was wir als einen gewissen Fortschritt in diesem Labyrinth betrachten können. Wenn also dieser Fortschritt durch das Labyrinth, den A prime gemacht hat, bedeutet, dass wir zu Teilen des Labyrinths, Teilen der Software gelangen, die beim Fuzzing noch nie zuvor erreicht wurden , dann wird diese Eingabe A prime als eine interessante Eingabe angesehen, die für weitere Überlegungen nützlich sein könnte . Also wird es wieder in den Korpus aufgenommen. Nennen wir es eine Primzahl. Ich bin hier etwas uneinheitlich mit den Farben. Das ist inOrdnung. Wir haben es verstanden. Wir haben es verstanden. Okay. Nehmen wir also an , es gäbe noch eine weitere Eingabe in diesem Korpus. Nennen wir es B. Und der Fuzzer hat B herausgezogen und eine Mutation darauf angewendet, um B' zu erhalten . Und dann wird B' an das SUT, das zu testende System, angelegt. Nehmen wir an, B' wiederholt einen Teil des Weges, den A' gegangen ist. Es erreicht also einen Teil der Abdeckung, vielleicht sogar die gesamte Abdeckung, die A Prime erreicht hat, aber keine größere Abdeckung. Dann wird B prime als uninteressant angesehen. Es ging nicht weiter. Von B prime haben wir nichts Neues gesehen . Es wird also nicht wieder in den Korpus aufgenommen, um weiteren Mutationen ausgesetzt zu werden. Nehmen wir aber an, dass A prime vom Fuzzer erneut ausgewählt und in eine Form A prime prime mutiert wird. Und wenn wir dies dem Fuzzer übergeben, dringt dieser tatsächlich ein Stück weiter in das zu testende System ein. Das ist ja toll. Ein absolutes Highlight ist es, Orte zu erreichen, die wir noch nie zuvor gesehen haben. Das ist interessant. Und es wird wieder in den Korpus aufgenommen, um in Zukunft berücksichtigt zu werden. Die Idee besteht darin, diesen Prozess schnell durchzuführen, idealerweise tausend- oder zehntausendmal pro Sekunde, und die Eingaben anhand der Abdeckung zu verändern. Neue Abdeckung ist also interessant, um sie immer ausgefeilter zu gestalten und tiefer in das System einzudringen. Und wenn wir Glück haben, ist es vielleicht das dritte Mal, dass wir diese Eingabe verändern. Wir gehen also von A prime prime aus. Nennen wir es A prim prim prim . Wenn wir dies dem System geben, könnte es sein, dass dies nun noch mehr Verbreitung findet und – zack! – dieser Fehler auftritt. Das System stürzt ab. Das ist ausgezeichnet. Wir haben eine Eingabe gefunden: Eine Primzahl, die zum Systemabsturz führt. Und nun kann unser Entwickler nachsehen, was falsch läuft und den Fehler beheben. Das ist also abdeckungsgesteuertes Fuzzing. Dies können wir als Beispiel für einen evolutionären Algorithmus betrachten. Wir haben eine Population, den Korpus, und wir haben das Konzept der zufälligen Mutation von Eingaben, also zufällige Mutationen in der Population. Ich erwähnte auch, dass eine der Mutationen darin besteht, mehrere Eingangssignale zu nehmen und sie miteinander zu verbinden, also Eingangssignale zu neuen Eingangssignalen zu verpaaren. Und wir haben eine Fitnessfunktion, sodass diese Eingaben nur dann überleben, nur dann wieder in den Korpus aufgenommen werden, wenn sie fit sind, was bedeutet, dass sie eine neue Abdeckung erhalten. Bei diesem Fuzzing- Ansatz geht es also darum, einen Korpus von Eingaben in immer komplexere Eingaben zu verwandeln, die immer tiefer in das zu testende System eindringen, um Fehler auszulösen. Nehmen wir an, wir haben ein Hilfsprogramm, das Befehlszeilenoptionen akzeptiert , zum Beispiel {dash} {dash}. Die Wahrscheinlichkeit, dass eine Eingabe mit einem Bindestrich am Anfang beginnt, ist ziemlich hoch. Es gibt nicht so viele Zeichen, und nach vielen Iterationen werden wir wahrscheinlich einen {Dash} finden, und es wird Code geben, der Befehlszeileneingaben verarbeitet, und dieser Code wird etwas tiefer, wenn wir einen {Dash} angeben. Wenn das nächste Zeichen aber kein Bindestrich ist, dann haben wir nicht {Bindestrich} {Bindestrich}, was den Beginn einer Eingabe darstellt. Da wir aber einen Bindestrich gefunden haben, wird dieser wieder in den Korpus aufgenommen. In Zukunft ist es recht wahrscheinlich, dass eine Mutation einen zweiten Bindestrich hinzufügt, und später werden wir beispielsweise den Buchstaben O und dann N usw. erhalten. Nach vielen, vielen, vielen Iterationen – aber nicht astronomisch vielen – wird der Fuzzer implizit das erwartete Eingabeformat erkennen und tiefer in das System eindringen. Wenn ich das Ganze nun umdrehe und der gesamte zweite Thread vor dem gesamten ersten Thread ausgeführt würde, hätte ich die symmetrische Situation, in der A gleich eins und B gleich null wäre. Die Frage ist, hätte ich auch beobachten können, dass A null und B null ist?

Wir verwenden immer noch TCP. Und wo stehen wir jetzt? Wir befinden uns auf der Transportschicht. Wir versuchen, Daten zwischen einer Anwendung auf einem Computer und einer Anwendung auf einem anderen Computer auszutauschen. Wir wollen diese Verbindung zuverlässig oder schnell gestalten. Im vorherigen Video haben wir also Mechanismen wie die Sequenznummer und die Bestätigungsnummer vorgestellt. Und wir haben die Idee, dass es eine Auszeit geben könnte. Lass uns eine Erinnerung einrichten. Wir haben also einen Sender und einen Empfänger. Das ist ziemlich merkwürdig, nicht wahr? Lass uns das in Ordnung bringen. Wir hatten also die Sequenznummer (SEQ) und die Bestätigungsnummer. Ich werde so tun, als wären das einfach nur ganze Zahlen. Das stimmt in Wirklichkeit nicht, aber tun wir mal so, als ob . In einem groben Modell würden wir Folgendes senden: Dies sind unsere Daten und dies sind die Daten mit der Sequenznummer eins. Und ich lasse hier etwas Platz, und Sie werden sehen, warum. Und ich werde eine Bestätigung zurücksenden, um mitzuteilen, dass wir die Daten erhalten haben. Das wird aber sehr langsam sein, wenn wir nur ein Datenpaket senden. Ein Datenpaket also etwa 1.500 Bytes groß. Das sind nicht viele Daten. Und wenn Sie eine dieser E-Mails senden, auf eine Bestätigung warten, eine weitere senden und wieder auf eine Bestätigung warten, wird das furchtbar langsam sein. Wir möchten viele davon gleichzeitig verschicken. Äh, sagen wir 1 2 3 4. Also, das wäre… Hier ist unser Traum. Wir senden diese fünf und bestätigen dann fünf weitere, wobei diese Bestätigung eine kumulative Bestätigung darstellt. Wir sagen: Okay, wir haben alles auf fünf hochgerechnet. Dies können wir nun als einen Flug von Datenpaketen bezeichnen. Es handelt sich also um Flüge oder Pakete, die sich noch im Flug befinden und für die wir noch keine Bestätigung erhalten haben. Sie als Absender können sich also sicher sein, dass Sie so und so viele Pakete versendet haben. Nun, soweit Sie wissen, existieren sie da draußen auf der Welt. Du weißt nicht, wie groß das Netzwerk ist, mit dem du verbunden bist, denn schließlich musst du dich mit allen verbinden, richtig? Sie könnten in Melbourne sein, sie könnten in Peking sein, sie könnten gleich nebenan sein. Es könnte eine riesige, wunderbare Glasfaserverbindung geben, oder es könnte sich um ein schreckliches Stück nasser Schnur handeln, das etwa zwei Bytes pro Jahr benötigt, und man muss mit dem arbeiten, was auch immer das ist. Vielleicht läuft es ja über einen Satelliten und das dauert sehr, sehr lange . Wie gehen wir damit um, dass wir die Größe dieses Netzwerks nicht kennen? Wir wissen nicht, wie lange es dauern wird, bis dies wieder der Fall ist. Wie können wir das effizient umsetzen? Bei Stauvermeidungsmechanismen besteht zudem das Problem der Umlaufzeit. Unser Ziel ist es, zu erkennen, wann es zu einer Überlastung des Netzwerks kommt. Mhm. Aber es gibt kein solches Netzwerk. Es ist nicht so, als gäbe es dort einen Stauanzeiger wie auf der Autobahn, der sagt: „Langsam fahren. Stau voraus.“ Ja? Wir brauchen einen Mechanismus, der das quasi automatisch erledigt. Welche Anzeichen könnten wir also verwenden, um auf ein Problem hinzuweisen? Nun, ich nehme an, Sie müssen die Zeit messen, die es dauert, bis die Bestätigung eintrifft. Ja, ja, ja. Das ist also wirklich wichtig. Wir nennen das also RTT, die Round-Trip-Time, und diese Round-Trip- Time ist für uns wirklich entscheidend, nicht wahr? Das ist also eine Sache, die wir auf jeden Fall tun können. In Ordnung. Neben den Hin- und Rückreisezeiten gibt es noch ein paar andere Dinge, die wir tun könnten. In Ordnung. Mhm. Ja, nun ja, man könnte sich ansehen, was sonst noch so los ist, zum Beispiel frühere Erfahrungen. Ja, ja, ja, absolut. Wir können uns also unsere bisherigen Erfahrungen mit der Hin- und Rückreisezeit ansehen. Wir begeben uns also in eine Welt, in der wir die Umlaufzeit messen und uns fragen: Schwankt sie? Die RFC, mit der wir es zu tun haben, die RFC, denken Sie daran, sind unsere Regeln, unsere Bitte um Kommentare ist so etwas wie die Bibel für uns Internetnutzer, die unsere Regeln festlegt. Und hier befassen wir uns mit RFC 5681 über Staukontrolle. Die TCP-Standards schreiben nun bestimmte Dinge vor, die Sie tun müssen. Sie haben diese Art von schöner Sprache, in der es heißt: Du solltest dies tun, du musst dies tun und du kannst dies tun. Es gibt eine Art Hierarchie. Ähm, einige Dinge im Übertragungssteuerungsprotokoll sind unerlässlich. Manche Dinge sind möglich. Ein gewisser Spielraum besteht. Wir nennen sie Aromen. Mit der Weiterentwicklung des Lebens und des Internets ändern wir also auch die von uns verwendete TCP-Variante . Heutzutage verwendet fast alles einen sogenannten Cubic-Aromen. Das ist derzeit die beliebteste Variante. Und der Geschmack hängt im Grunde davon ab, wie wir auf diese Signale reagieren. Wann sagen wir, dass ein Datenpaket verloren gegangen ist? Und wie reagieren wir darauf? Der wichtigste Reaktionsmechanismus besteht in der Idee eines Überlastungsfensters. Als wir das letzte Mal so etwas gemacht haben, haben wir dieses Fenster abgespielt, und ich sagte: „Nicht jenes Fenster.“ [Gelächter] Und mit „Fenster“ meinen wir die Anzahl der Pakete, die sich derzeit im Netzwerk befinden. Es handelt sich um die Anzahl der Bytes, von denen wir glauben, dass das Netzwerk sie verarbeiten kann. Es gibt zwei Fenster. Nun, ich werde diesen Punkt nur kurz behandeln, denn er ist eigentlich nicht so wichtig. Dieses Fenster hier ist also unser Empfangsfenster. In den Anfängen des Internets befand sich der Empfänger wahrscheinlich im selben Labor wie Sie, nur um das Experiment zu ermöglichen. Vielleicht lief er etwas langsam und sagte dann: „Hey, ich habe Platz für 100 Kilobyte Daten. Senden Sie mir nicht mehr als 100 Kilobyte. Ich kann das nicht verarbeiten.“ Und das wird im Paketheader gesendet. Das bedeutet also, dass Sie nicht mehr als diese Anzahl Bytes an Daten in der Welt haben möchten, da Ihr Empfänger sie sonst möglicherweise verwerfen muss, weil er damit nicht umgehen kann. Das ist in der Realität nicht wirklich so wichtig, oder besser gesagt, es ist in der Welt nicht so wichtig wie das Staufenster. Das Überlastungsfenster wird vom Sender und Empfänger überwacht, und sie prüfen ständig, „Wie viele Daten kann dieses Netzwerk meiner Meinung nach senden?“ Es gibt zwei Signale, die wir uns ansehen könnten. Die meisten von ihnen schauen sich einfach nur ein verlorenes Signal an. Die meisten TCP-Varianten prüfen also lediglich, ob tatsächlich ein Paket verloren gegangen ist? Ja? Diese Bestätigungen sind also nummeriert, und wenn wir keine Bestätigung erhalten, wenn keine Rückmeldung kommt, oder, wie wir auch gesagt haben, „wenn die falsche Nummer einer Bestätigung zurückkommt“. Stellen wir uns also vor, dieses Paket stirbt zweimal. Dann teile ich es mit . Also, hier ist die Zahl zwei, hier die Zahl drei, vier und fünf. Paket zwei ist irgendwo verloren gegangen. Also, was ich hier tatsächlich zurücksenden werde, ist ACK eins ACK eins ACK eins nochmals. Also, ich sage immer wieder ACK eins, ich habe Paket eins erhalten. Ich habe ein weiteres Paket erhalten, es war nicht das, was ich wollte. Ja? Denken Sie daran, dass wir in diesen Dingen nicht zu viele Informationen vermitteln können. Das sollte man sich einfach vor Augen halten. Wir können nichts Kompliziertes sagen wie: Ich habe die Pakete 1, 3, 5, 7 und 8 erhalten, aber zwei fehlen, und könnten Sie mir bitte helfen? Zu viele Daten. Ja, so ist dieser Mechanismus nicht konzipiert. Das alles steckt in einer Kopfzeile. Wir wollen keine Informationen im Umfang eines Telegramms versenden. Wir möchten so wenige Informationen wie möglich übermitteln, um unsere Aufgabe zu erledigen. Deshalb verwenden wir eher ungewöhnliche Signale. Es gibt auch andere Mechanismen, die das leisten könnten. Jetzt ist nicht die Zeit, sich damit zu befassen. Wir senden also diese ACK-Nachricht und senden sie wiederholt, um mitzuteilen, dass dieses zweite Paket fehlt. Bis wir also ein ACK erhalten, das die Sequenzpakete eins und drei weitere bestätigt. Dies ist ein dreifaches Duplikat. Und nun vermuten wir äh [schnaubt], dass mit Paket zwei wohl etwas Schlimmes passiert ist . Dafür muss ich einige Dinge erledigen. Was ich dafür tun muss, ist natürlich, dass das zweite Paket erneut verschickt werden muss. Aber jetzt muss ich mir überlegen, ob ich das Netzwerk überlaste. Sende ich zu viele Daten? Noch schlimmer als ein dreifaches Duplikat zu erhalten, wäre es vielleicht, wenn ich sie alle verschicken würde. Und nichts. Gar nichts . Nichts kommt zurück. Wenn ich jetzt also alle Daten sende, kommt nichts zurück. Ich glaube, du hast… Nun, vielleicht ist mein Netzwerk katastrophal überlastet, oder? Wenn ein Datenpaket verloren geht, beispielsweise weil ein Puffer übergelaufen ist oder weil es einfach nur zufällig beschädigt wurde oder irgendetwas schiefgelaufen ist. Aber wenn ich gar nichts bekomme, wenn ich nur eine Auszeit kassiere, denke ich jetzt: „Mein Gott, hier herrscht aber ein ziemliches Gedränge.“ Hier kommen also die verschiedenen TCP-Varianten ins Spiel . Wir brauchen also noch ein Blatt Papier. Wir müssen uns überlegen, wie ich meine Fenstergröße weiterentwickeln kann. Also, grob gesagt, ich nenne es mal so, obwohl es eigentlich eher eine Art Uhr zwischen den Bestätigungen ist. Und das ist das Ausmaß des Staus, des C W N D. Nun, ich fange hier etwas ungewöhnlich an, aber Sie werden gleich sehen, warum. Wenn ich alle meine Pakete versende, zählen wir sie alle heraus, zählen sie alle zurück, und das ist ein Erfolg. Ich werde mein Fenster ein Stückchen hochkurbeln. Ich habe also eine Runde Päckchen gezählt, alle sind zurückgekommen. Großartige Neuigkeiten. Das Netzwerk ist also vielleicht doch etwas größer, als ich dachte. Man kann es also gewissermaßen pushen. Ja, ja, ja, ich werde es versuchen [räuspert sich]. Ja, 65 Meilen pro Stunde sind gut. Versuchen wir es mit 70. 70 war gut, versuchen wir es mit 75. Wir werden also die Fenstergröße schrittweise erhöhen. Okay, es wird immer größer. Aber wenn wir verlieren, werden wir den Ball wieder zu Boden werfen. Wir werden es wahrscheinlich halbieren . Also, wir halbieren vielleicht unser Fenster und vergrößern es dann langsam wieder . Wenn ich das dreifache Duplikat bekomme, werde ich es halbieren. Bam, bam, bam. Und fang an, es langsam wieder hochzutreiben. Theoretisch erhalten wir so eine Art Sägezahnmuster. Im Falle eines katastrophalen Verlustes müssten wir vielleicht von vorne anfangen, aber ich habe diesen Teil ausgelassen, weil ich noch nicht wirklich darüber gesprochen habe, wie wir angefangen haben. Denn was wir erreichen wollen, ist Folgendes: Diese Fenster können recht groß sein und eine beträchtliche Menge an Daten enthalten. Und wenn wir damit anfangen, es langsam aufzubauen. Oh, ich habe dem Ganzen keinen Namen gegeben. Wir sollten diesen Namen verwenden. Wir nennen dies AIMD, additive Steigerung multiplikative Abnahme. Ich werde das Fenster um ein Paket vergrößern, wenn wir alle erfolgreich zurückbekommen, aber wenn ich eine Überlastung feststelle, werde ich den Vorgang schnell beenden. In Ordnung? Ich möchte die Dinge nicht schleichend verschlechtern und das ohnehin schon überlastete Netzwerk weiterhin überfordern. Also, additive Steigerung, ich tauche um eins auf. Multiplikative Verringerung, also halbieren. Aber zu Beginn wollen wir etwas aggressiver vorgehen. Denn wenn wir anfangen und ein Paket senden, und dann zwei, drei, vier, fünf Pakete, dann ist das Leben zu kurz. Ja , genau. Das Leben ist viel zu kurz. Es wird noch eine Weile dauern, bis wir tausend Pakete versenden. Wir haben also vielleicht einen der schlimmsten Namen in der Computerbranche, und wir haben das, was wir hier „langsamer Start“ nennen. Wir nennen es einen langsamen Start, weil es ungeheuer schnell geht. Ich weiß. Ich habe es nicht benannt. Ähm nein, es geht darum, den langsamen Start zu überwinden. Also, ich werde jetzt die Fensterpaketnummern angeben, was ich eigentlich nicht tun sollte. Eigentlich müsste es in Bytes angegeben werden, aber um es einfacher zu machen. Also, ich werde ein Paket senden. Schau, ob es wiederkommt. Ich werde jetzt zwei schicken. Nun werde ich [räuspert sich] vier senden. Jetzt schicke ich acht. So, ich schicke jetzt 16. Hoch hoch hoch hoch hoch, es geht nach rechts. Die Anfangsphase ist also durch exponentielles Wachstum gekennzeichnet. Nur um uns aus dieser Sackgasse herauszuholen, in der alles wirklich sehr, sehr langsam vorangeht. Und wenn wir dann den ersten Verlust hatten und die Verbindung ordnungsgemäß funktioniert, werden wir zur additiven Zunahme und multiplikativen Abnahme übergehen. Man könnte also bis auf 1024 hochschnellen, dann aber Verluste erleiden, also werden wir wieder nach unten gehen und zu diesem AIMD zurückkehren. Und hier kommen wir zu den Geschmacksrichtungen, denn erstens, wie bereits erwähnt, gilt: „Okay, wenn wir diese Duplikate zurückbekommen, können wir auf einen Verlust schließen.“ Es könnte aber auch zu einem Timeout- Verlust kommen, weshalb wir das Spiel etwas später beenden werden. Wie lange müssen wir warten? Mhm. Wir denken also an die Gesamtreisezeit zurück. Äh, hier kommen verschiedene Algorithmen zum Einsatz, aber wir werden ein Vielfaches dieser Umlaufzeit warten. Wir werden also messen: „Oh, es hat 0,1 Sekunden gedauert, bis alle diese Pakete verarbeitet waren.“ Ich werde ein Vielfaches davon abwarten und dann sagen: „Wenn wir bis dahin keine Bestätigung erhalten haben, ist etwas wirklich Schlimmes passiert.“ Das war’s . Genau dort wird das Timeout an die Umlaufzeit angepasst . Das bedeutet, dass wir denselben Algorithmus sowohl für ein Rechenzentrum als auch für eine Strecke nach Australien einsetzen können, wo die Laufzeiten sehr, sehr unterschiedlich sind. Derselbe Algorithmus oder sogar bis hin zu einem Satelliten kann mehr oder weniger derselbe Algorithmus funktionieren. Ähm, besorgt euch was Vernünftiges, denn sie müssen sich erst an die Hin- und Rückreisezeit gewöhnen. Die Leute sehen das und wollen sofort daran herumtüfteln und sagen: „Oh, na ja , schau dir das mal an.“ Ja, das scheint eine Verschwendung zu sein, nicht wahr? Und im Laufe der Jahre wird sich genau zeigen, wo man seinen langsamen Start beendet, wann man ihn halbiert und wann man ihn erhöht. Und deshalb haben wir am Ende all diese Geschmacksrichtungen, wie zum Beispiel… Und ich sagte ja schon, in dem Moment, in dem… Oh, die Geschmacksrichtung des Monats ist tatsächlich Cubic, was die meisten… äh… ich glaube, die Leute werden mich umbringen, wenn ich das falsch wiedergebe. Ich glaube, Windows, Mac und Linux verwenden alle diese. Es gibt noch andere Dinge, die sie verwenden können. Manche dieser Algorithmen analysieren die Umlaufzeit und sagen: „Oh, die Umlaufzeit steigt. Ich werde die Verbindung sperren, falls dies auf eine Überlastung hindeutet.“ Das ist also eine andere Möglichkeit. Die meisten von ihnen arbeiten jedoch mit dem Verlustsignal. Die Leute sehen sich das an und denken: „Das könnte ich besser machen. Da lässt sich bestimmt noch was verbessern. Was wäre, wenn wir die Bandbreite halbieren oder sogar um drei Viertel reduzieren?“ Wir sollten uns also die Situation in der Praxis ansehen und feststellen, dass sie nicht so perfekt aussieht wie hier. Und wir werden auch sehen, warum … Wenn wir an die Anfänge dieses Netzwerks denken, waren die frühen Netzwerke wirklich langsam, nicht wahr? Man konnte froh sein, wenn ein paar Kilobit pro Sekunde durchkamen. Heutzutage hingegen denkt man: „ Ich habe zwar einen Gigabit- Anschluss, aber der reicht nicht wirklich aus.“ Und ja , wir alle wollen mehr Bandbreite, richtig? Und dann heißt es: „Oh, könnte ich nicht zehn Glasfaserkabel zu mir nach Hause bekommen?“ Wir werden uns das mal in der Praxis ansehen, ein paar echte Datenpakete analysieren und feststellen, dass die Situation für TCP nicht so reibungslos ist, wie sie scheint. Ich habe es hier vorgestellt. Was bedeuten also die verschiedenen Farben ? Sie geben Aufschluss über die Art der Protokolle und welches Protokoll jeweils verwendet wird . Wir werden später sehen, dass einige schwarze Symbole auf ein schwerwiegendes Problem hinweisen. Dieses hier zeigt an, dass ich es markiert habe. Wir werden nun diesem Datenstrom folgen, von dem ich hoffe, dass er der richtige ist. Ja, das ist er. Ich lade hier eine große Datendatei – ich glaube, sie ist etwas über ein Gigabyte groß – von meinem virtuellen Server in Manchester herunter, über eine relativ kurze Netzwerkverbindung. Wireshark soll diesen TCP-Datenstrom rekonstruieren. Wireshark findet also alle zugehörigen Pakete, sodass wir uns die Kommunikation ansehen können, beginnend mit SYN-ACK-ACK. Wir werden sehen, dass die Dinge etwas komplexer sind, als wir es im Unterricht lehren. Hier finden wir die Pakete direkt am Anfang des Datenstroms, genau wie ich es beschrieben habe. Wir haben also eine SYN-ACK- und eine ACK-Nachricht. Sofort ändert sich die Situation, da wir jetzt die Transportschichtsicherheit (TLS) darüber haben . Diese Schicht sorgt für die Sicherheit, gehört aber nicht zu Schicht 4. Daher kümmern wir uns heute nicht darum. Sie gewährleistet jedoch die Sicherheit. Wir haben also eine Menge Verschlüsselungsalgorithmen. [schnaubt] Und nun wieder etwas TLS . Hier sehen wir die Quell-IP 5.28.62.245. Das ist mein Server in Manchester. 192.168.68 ist eine lokale Adresse, die manch einer wiedererkennen dürfte. Das ist eine lokale Adresse in einem Heimnetzwerk. Das ist also mein Rechner zu Hause. Und hier steht, dass der Server Byte Daten und eine 66 Byte Bestätigung als Antwort gesendet hat. Wenn Sie im Netzwerkbereich arbeiten, würden Sie sich bei dieser Zahl 2766 sofort Sorgen machen, denn Das ist größer als es sein sollte. Ähm, und es stellt sich heraus, dass ich eine Menge Mesh-Technologie in meinem Heimnetzwerk habe. Dadurch werden Pakete auf eine Weise zusammengefügt, die ich nicht erwartet hatte. Wir sehen also bereits etwas, das nicht mehr dem sauberen, reinen Netzwerksignal entspricht, das wir normalerweise senden würden. Das ist nicht das, was über das Internet gesendet wurde . Mein Heimnetzwerk verbindet sie irgendwie. Außerdem wird das Ganze regelmäßig von diesen TLS-Paketen getaktet. Sie sorgen also für zusätzliche Sicherheit . Hier sehen wir vier wieder zusammengesetzte TCP-Segmente mit 8.000 Bytes. TLS fügt also die zusätzlichen Sicherheitsinformationen zu den Daten in diesen TCP- Paketen hinzu. Hier sehen wir ein Paket. Wir sehen die zugehörige Sequenznummer und die Bestätigung, die zurückkommt. Als ich von Sequenznummer und Bestätigung sprach, meinte ich, dass ich eine vereinfachte Version zeige, denn diese Sequenznummern und Bestätigungen sind nicht einfach nur 1, 2, 3, 4. Sie geben an, welche Bytes wir gerade betrachten. Und im Fall der Bestätigung, welches Byte wir erwarten. Schauen wir uns an, wie sich dieses TCP-Fenster entwickelt. Ich habe ein kleines Code-Snippet geschrieben, das die Aufzeichnungsdatei meines Heimnetzwerks durchläuft. Es fragt alle 100 Millisekunden ab: Wie viele Bytes haben wir gesendet? Es läuft gerade . Seit Beginn der Datei sind 23, 24 Sekunden vergangen. Hier ist die Anzahl der übertragenen Bytes. Es ist nur ein kleines Python-Snippet, das ich schnell zusammengeschrieben habe. Ich gebe Shawn den GitHub-Link, falls er es in seinem eigenen Netzwerk ausprobieren möchte. Anschließend wird ein einfaches Diagramm im Matplotlib-Stil ausgegeben. Vergrößern wir es. Und hier sehen wir Folgendes. Ist das nicht eine schöne Sägezahnkurve? Wenn diese Kurve beginnt, dauert es tatsächlich eine Weile. Also, das hier – das ist nicht meine beste Skala. Megabyte pro 100 Millisekunden. Aber das zeigt, wie viele Daten in dieser 100- Millisekunden-Stichprobe enthalten waren. Und die orange Linie ist der Mittelwert aus 10 Stichproben, um eine schönere Kurve zu erhalten. Wenn sie so stark abfällt, bedeutet das, dass in dieser 100-Millisekunden-Stichprobe überhaupt keine Daten vorhanden waren. Oder nun ja, nicht ganz keine, aber eine sehr geringe Datenmenge . Aber wir sehen nicht diesen additiven Anstieg und multiplikativen Abfall. Wir sehen ein viel zackigeres, komplexeres Verhalten, weil so viele Dinge gleichzeitig passieren. Wir konkurrieren mit vielen anderen um den Platz . Wenn viele Leute dieses erste Diagramm sehen, denken sie: „ Oh, wir könnten es effizienter gestalten, wenn…“ „ Wir optimieren hier und da noch etwas.“ Ich zeige euch noch ein Beispiel. Also, das hier war der Download einer Datendatei mit Wget. Wget ist einfach ein Befehl, der eine benannte Datei aus einem Netzwerk herunterlädt. Hier lade ich also die neueste Ubuntu-Distribution von deren Website herunter, und das Ganze wiederholt sich, sodass ich wieder denselben Verlauf erlebe. Wir werden dieses zackige Verhalten sehen, bei dem wir im echten Leben nicht beobachten, dass die Geschwindigkeit an eine Grenze stößt und wieder abfällt. Aber was ihr hier seht, und was ich absolut liebe, ist der langsame Start, nicht wahr? Ja. Wir können den – ich war ehrlich gesagt so glücklich, als ich das sah. Es ist einfach wunderschön. Ich schwöre, ich schwöre, das sind echte Daten. Ich habe das nicht gefälscht. Es ist echt. Ja, also ein wunderschöner, langsamer Start, der uns langsam nach oben bringt. Also, angesichts meiner Dummheit … Skaliert man das, erreicht man etwa 10 Megabyte pro Sekunde, bevor der Slow- Start-Mechanismus hier Probleme bereitet. Wir sehen also den schönen Slow-Start- Mechanismus, der im vorherigen Diagramm nicht zu sehen war. Ich denke, wir haben großes Glück, das in freier Wildbahn zu beobachten. Und dann passiert eben das Leben, nicht wahr? Wie Sie schon sagten, im Internet ist ständig etwas los, die Bandbreite steigt und halbiert sich . Sie steigt und halbiert sich wieder. Vielleicht steigt sie beim nächsten Mal etwas höher und dann wieder niedriger. Ja, ja, ja, ja. Meine abschließende Botschaft dazu ist: Wenn wir über TCP nachdenken, denken viele, es sei total unkompliziert. Nun ja, wenn man beispielsweise ein Signal sendet, das besagt, dass Route 5 zu 53 % ausgelastet ist, und wir nicht wissen, wie viele Pakete genau überwacht werden, dann hat man zwei Probleme. Man hat ein Problem. Ein Großteil des Mechanismus ist fest vorgegeben, richtig? Im vorherigen Video habe ich den Paketheader gezeigt. Dort ist etwas Platz, und es gibt ein paar Bits, die man nutzen könnte, wenn man wollte. Das würde aber wahrscheinlich Probleme verursachen, da Zwischengeräte und Firewalls diese Daten überwachen und auf Unregelmäßigkeiten achten . Wenn man also daran herumexperimentiert, blockieren einige Zwischengeräte möglicherweise den Datenverkehr und fragen sich: „Was passiert hier?“ Da ist doch was faul, oder? „Das werden wir loswerden .“ Man hat also nicht viel Spielraum für Anpassungen, und außerdem befindet man sich in einer ziemlich unübersichtlichen Welt. Das reale Internet ist wirklich viel komplexer als die Skizzen, die wir im Unterricht anfertigen. Ähm, und so ähnlich ist es auch mit dem TCP- Protokoll, das aus den 80er-Jahren stammt. Es war das erste Protokoll, das funktionierte, und dann wurde es sozusagen angepasst, so als ob wir das Modell T gebaut hätten und die Leute dann fragen würden: „ Warum hat es keinen Getränkehalter?“ Warum hat es kein Bluetooth? Warum ändert sich der TCP-Header nicht? Ändert er sich wirklich sehr, sehr langsam? Darin können sich die Dinge ändern , aber seit den 80er Jahren hat sich eigentlich nicht viel verändert. Es hat sich einige Flaggen erworben und sich etabliert. Und man kann nicht zu viel signalisieren. Man kann nicht sagen: „Ich werde einen Mechanismus einbauen, der all diese neumodischen Dinge tun wird, die ich mir ausgedacht habe, und der dieses Problem lösen wird.“ Also, ähm, in der realen Welt erfüllt TCP seinen Zweck und das schon seit fast 50 Jahren sehr, sehr gut. Ähm, es gibt so viele Dinge, die ich in diesem Video ausgelassen habe. Es gäbe noch so vieles hinzuzufügen. Aber ich denke, wir haben jetzt die Mechanismen gesehen, die dafür sorgen, dass es funktioniert. Wir haben gesehen, dass es im wirklichen Leben ziemlich kompliziert ist. Es ist eine chaotische Welt, mit der es zu tun hat . Und es geht nicht nur darum, dass die Daten einfach in irgendeinem Rechenzentrum landen. Es muss damit umgehen können, wenn es um die Kommunikation innerhalb des Heimnetzwerks, über einen Satelliten oder Ähnliches geht. Trotz ihres Alters leistet sie also eine sehr, sehr, sehr gute und komplexe Arbeit. Das Besondere an einem VPN ist, dass wir so etwas wie einen Durchgang schaffen, sodass der erste Router, an dem unser Datenverkehr ankommt, in einem anderen Land liegt. Also unser

Äh, nun ja, heute werden wir über den Clever-Hans-Effekt sprechen. Okay, wer ist denn nun dieser Hans? Ich weiß nicht, ob man „who“ für ein Tier verwenden kann . Clever Hans war also ein Pferd, das Ende der 1890er Jahre in Deutschland geboren wurde. Das ist unser heutiger Schlaumeier Hans. Er war ein außergewöhnliches Pferd. Er konnte Mathematik und andere Arten von Fragen beantworten. Er würde also öffentlich ausgestellt werden und jemand würde ihn fragen: „Was ist 3 + 3, Hans?“ Und dann würden sie anfangen zu zählen, denn Pferde können ja offensichtlich nicht sprechen. Geh 1 2 3 4 5 und das Pferd wiehert, stampft mit den Hufen, Ja. und es wären sechs. Toll. Und er konnte auch andere Arten von Problemen lösen, nicht nur mathematische. Der sogenannte „Clever-Hans- Effekt“ ist also etwas, das wir insbesondere im Bereich der KI beobachten . Hat Hans Mathematik betrieben? Fraglich. Nun ja, das ist tatsächlich noch immer umstritten. Okay. Äh, und wir werden es nie erfahren, weil Hans im Ersten Weltkrieg starb und wahrscheinlich gegessen wurde. Armer Hans. Aber ein bestimmter deutscher Psychologe meinte, Hans würde keine Mathematik betreiben. In Ordnung . Er beobachtete die Körpersprache. Hans war also clever, aber er zählte nicht. Okay. Der Fragesteller, also unser Fragesteller, würde fragen: „Was ist 3 + 3?“ Und wenn die richtige Antwort in greifbare Nähe rückte, gab es ein unwillkürliches Signal dafür, dass Hans gelernt hatte. Rechts. Also, äh, Hans würde dann „ooh“ sagen, fast wie eine Pawlowsche Reaktion, aber etwas differenzierter, weil es mehr Arten von Auslösern gab. Äh, und ein Modell, ein KI-Modell, könnte genau dasselbe tun. Also, lasst uns über den Clever-Hans- Effekt in der Musik sprechen. Also, ich glaube vor etwa 12 Jahren gab es eine Arbeit von einem Mann namens Bob Sturm, und er sagte, dass Musikklassifizierungsmodelle eigentlich alle Pferde sind, sie sind einfach nur Schlaumeier. Und ich kann beweisen, dass dies der Fall ist, denn er hat einfach Klassifikatoren und Musikstücke genommen und dann Equalizer-Filter und Verzögerungen angewendet, und das hat die Klassifizierung verändert. Man hatte also Rockmusik, fügte etwas Delay hinzu, und plötzlich sagt das Modell, es sei Reggae. Aber er weiß nicht, warum das passiert ist. Wir werden uns heute also ansehen, warum das passiert. Wenn Sie nun eine Frage stellen möchten, eine Warum-Frage in der Informatik oder ganz allgemein, benötigen Sie wahrscheinlich Kausalität. Was genau in der Musik hat das Modell dazu veranlasst, zu sagen, es handele sich um Rock oder um Reggae? Ich hoffe, es ist allgemein bekannt, dass Audio als Welle dargestellt werden kann. Das könnte, ich weiß nicht, so ähnlich aussehen. Okay, wir haben also unser Signal, und das ist die Zeit entlang dieser Achse, und das ist die Amplitude, die wir als Lautstärke bezeichnen können. Ich werde da nicht so pingelig sein. Und nun kommt der große Sprung. Es gibt also etwas, das man Fourier- Transformation nennt. Es gibt wahrscheinlich schon unzählige Videodateien dazu. Vielleicht. Oder Computerdatei. Das sollte so sein. Ich werde heute nicht näher darauf eingehen, da es mathematisch ziemlich kompliziert ist, aber im Wesentlichen lässt sich dieses Signal in eine Vielzahl unterschiedlicher Sinussignale zerlegen, jedes mit einer anderen Frequenz. Es könnte also etwa so aussehen. Sie haben einen wie diesen, und Sie können einen wie diesen haben, und dann haben Sie vielleicht noch einen wie diesen. Und wenn man sie alle zusammenrechnet, erhält man das. Wir wollen die Hypothese testen, dass unser Modell keine musikalischen Informationen nutzt, sondern etwas anderes tut, eine Art Abkürzungslernen. Eine Möglichkeit, dies zu tun – es ist nicht die einzige –, die ich angewendet habe, besteht darin zu sagen: „Nun, lasst uns dieses Signal in all seine verschiedenen Frequenzkomponenten zerlegen.“ Das Ergebnis ist etwas, das üblicherweise als FFT bezeichnet wird, die schnelle Fourier-Transformation. Und es könnte so aussehen. Auf der x-Achse haben wir also die Frequenzen. Und hier haben wir die Amplitude. Und Sie erhalten etwas, das aussieht wie ein Histogramm davon. Ja , genau. Histogramm der Um. Es ist nicht ganz ein Histogramm, aber nah genug dran . Uh der im Signal vorhandenen Frequenzen. Und dann können wir uns die Frage stellen: Welche Frequenzen werden benötigt? Welche Mindestinformationen kann ich dem Modell übergeben, um anzunehmen, dass dies als „Blues“ klassifiziert wurde? Mhm. Benötige ich all diese Informationen, damit es sich um den Blues handelt? Ich meine, vielleicht tue ich es ja, aber wir wissen es nicht. Wie werden wir das also herausfinden? Ich könnte jede einzelne Frequenzkombination testen. Das ist Wahnsinn. In einem 30-sekündigen Audioausschnitt, wie er von unseren Klassifikatoren verwendet wird, gibt es diese sogenannten Frequenzbänder etwa 240.000 davon. Das kann ich also nicht im Kopf machen. Äh, das ist eine große Zahl, wenn wir alle möglichen Kombinationen betrachten. Das werden wir also nicht tun . Wir werden sozusagen einen Divide-and-Conquer- Algorithmus anwenden, zu dem Sie ja bereits ein Video gesehen haben. Hannah Chocoler sprach darüber, ich glaube, es hieß damals Deep Cover. Es heißt jetzt Rex. Schau es nach. Äh, also, wir werden eine ähnliche Technik anwenden. Und wir werden das Ganze nun nach dem Zufallsprinzip in Stücke aufteilen. Und [schnaubt] also, jetzt haben wir 0, 1, 2 und 3. Und wir können uns die Kombinationen davon ziemlich einfach ansehen. Wir schauen uns also die Kombinationen an und sagen, dass für die blauen Zahlen 0 und 2 benötigt wurden. Okay, gut. Dann können wir das Gleiche noch einmal machen . So, jetzt werden wir das los. Auf Wiedersehen. Und wir können diese weiter unterteilen und immer weiter suchen, immer weiter suchen, immer weiter suchen. Das heißt jetzt 0 1 2 3, bis sich schließlich herausstellt, dass wir für den Klassifikator vielleicht nur dies und dies benötigten . Sich darüber zu freuen, dass das der Blues ist. Das genügt. Um den Klassifizierungsblues zu bekommen. Das nennen wir also ein ausreichendes Signal. Ich spiele dir später noch ein paar vor, damit du entscheiden kannst, ob sie dir genügen oder nicht. Das ist also ein ausreichendes Signal. Davon bekommt man wieder einen Blues. Ähm, aber das ist nicht notwendig. Was meine ich damit ? Das bedeutet, wenn ich diese Frequenzen entferne, mal sehen, ob ich das dann ungefähr gleich neu zeichnen kann. Das ist also der Blues, und da sind wir uns einig. Ich hoffe. Dass dies und das. Reichen für den Blues. Was aber, wenn ich diese einfach entferne und alles andere unverändert lasse? Das könnte immer noch der Blues sein. Es kann mehr als einen Grund geben. Warum das Model glaubt, es sei traurig. Und ich halte das für absolut angemessen. Wir können also auch das berechnen, was wir eine vollständige Erklärung nennen. Also komplett. Das bedeutet, dass es ausreichend ist. Für sich genommen ist es also der Blues. Und wenn ich es entferne. Indem man diese Frequenzwerte einfach auf Null setzt. Es ist nicht mehr der Blues. Wir können also buchstäblich den Blues aus dem Audio extrahieren. Aber ich meine, für unsere menschlichen Ohren klingt es doch irgendwie immer noch nach Blues, oder? Nun, das ist. Äh. Weil wir vor ein paar Jahren ein Video über Bildklassifikatorbrände gemacht haben, in dem es darum ging, etwas Rauschen hinzuzufügen und, keine Ahnung, einen Tacker in einen Laptop zu verwandeln. Kurz gesagt, um Ihre Frage zu beantworten. Ausgezeichnete Frage. Ja. Äh, im Grunde genommen zeigt es nur auf, dass diese Modelle es nicht sind. Das sind Pferde. Das ist ein cleverer Hans. Ähm, sie tun nicht das, was wir erwarten würden. Wenn ich Sie also fragen darf. Äh. Ich werde meine Gitarre aufklappen. Wenn ich Sie also fragen würde. Was der Blues ist. Ich meine, ich werde so etwas wie einen 12-taktigen Blues spielen. Ganz einfacher 12-taktiger Blues. Woran erkennt man, dass es sich um Blues handelt? Was würdest du sagen? Ja . Ich glaube, das ist ein Muster, das ich schon einmal gehört habe. So würde ich es ausdrücken. Nun, genau das tut ein Model auch . Ja . Aber ich stelle mir vor, wie jemand auf der Treppe vor einem, wissen Sie, es weckt Assoziationen. Okay, du meinst also, dass es da so etwas wie eine emotionale Person gibt, deren Leben aus den Fugen geraten ist und dann ist auch noch ihr Hund gestorben und all diese Dinge. Nun ja , viel Blues ist auch ziemlich lüstern. Es könnte sein, dass ich dein Hintertür-Mann bin und eine Affäre mit deiner Frau anfangen werde. Oh ja . Ich bin es nicht. Ich weiß nicht, wo sie wohnt. [Gelächter] Wahrscheinlich geht es dabei eher um mehr als nur um das, nicht wahr? Ja, wahrscheinlich. Das ist also eine knifflige Frage, nicht wahr? Es gibt eigentlich keine wirklich einfache Antwort darauf, warum das der Blues ist. Wir sprechen über den Rhythmus. Wir sprechen über die Instrumentierung. Wir könnten über die harmonische Progression, die genaue Phrasierung sprechen. Tun das auch Models? Im Idealfall ja. Aber wahrscheinlich nicht. Aber wahrscheinlich nicht. Und um es vorwegzunehmen: Die Tatsache, dass wir das können, beweist, dass sie es nicht können. Denn es wäre, glaube ich, nicht möglich, davon einige Frequenzen abzuziehen und Sie davon zu überzeugen, dass ich Bach spiele. Okay, ja. Vielleicht könnte ich es, aber wahrscheinlich nicht. Wir haben also das Nötigste für den Blues. Wir haben das komplette Paket. Nur ein kleiner Exkurs, okay? Wenn man das auf einer Marimba spielen würde, würden die Leute dann immer noch denken, es sei Blues? Möglicherweise nicht, denn, wie bereits erwähnt, spielt die Klangfarbe bei solchen Dingen eine sehr wichtige Rolle. Wenn ich das also auf einem Saxophon oder einer Marimba spielen würde, wäre das eine interessante Wahl. Ich habe mich einfach für etwas völlig anderes entschieden, ja. Weißt du [Musik] was? Das wäre ein tolles Experiment. [Musik] Ich führe nicht viele Nutzerstudien durch. Ich weiß nicht, wie man sie einrichtet, aber ich denke, das wäre ein Experiment für eine Nutzerstudie. Wir haben also ein vollständiges Ergebnis, was bedeutet, dass es sowohl ausreichend als auch notwendig ist. Wenn ich es also wegnehme, erhalten wir eine neue Klassifizierung. Die Frage ist also: Wie sieht diese neue Klassifizierung aus? Wir nennen das also die Umkehrung, was kein besonders aufregender Name ist. Und das mag existieren oder auch nicht. Wenn die Modelle also tatsächlich das tun würden, was wir wollen, dann müsste das vollständige Signal ausreichend und notwendig sein . Es sollte keine Umkehrung geben. Es sollte nicht möglich sein, die Klassifizierung durch einfaches Subtrahieren einiger Häufigkeiten zu ändern. Ähm , ich habe jetzt ein Beispiel, das wir uns anhören können. Um es gleich vorwegzunehmen: Ich habe ein extremes Beispiel gewählt [Gelächter], damit Sie den Unterschied wirklich hören können . Ähm, also , hören wir mal rein. Okay, also was wir hier haben, ist äh ein Beispiel, das ich vorab aufgenommen habe. Ich wollte es eigentlich live machen, aber, na ja, die Nerven haben mich im Stich gelassen . Also, äh, das ist mein 11-jähriger Sohn am Schlagzeug. Hallo William. Ähm, also, es ist ein ganz normaler Blues. Ich denke, wir sind uns einig, dass es der Blues ist. Ich entschuldige mich für das miserable Gitarrensolo am Ende. Ich bin kein Bluesmusiker. Das klingt für mich bluesig. Es ist in Ordnung. Sie verstehen schon. Das ist also der Originalton. Denken Sie also daran, dass wir über ausreichende Signale gesprochen haben. Was ist die minimale Anzahl an Frequenzen, die ich an einen Klassifikator übergeben kann ? Ich werde Ihnen nicht sagen, welcher Klassifikator. Es ist öffentlich zugänglich, aber ich möchte sie nicht in Verlegenheit bringen, da es kein besonders guter Klassifikator ist. Wie viele Frequenzen muss ich mindestens übergeben, um die Klassifizierungsprobleme wieder zu lösen? Und das Schöne daran ist, dass wir es uns anhören können . So, es ist da. Das ist es. Vergleichen wir es mit dem Original. Im Großen und Ganzen kann man sehen, dass es an ähnlichen Stellen lautere Passagen gibt. Es folgt in etwa der gleichen Kontur, aber man kann sehen, dass es nicht dasselbe ist. Möchtest du es hören? Hören wir mal rein . [Musik] Der Blues. Nun, du hast es auf dem Bildschirm blau gemacht. Ich meine, das ist das Einzige, was daran blau ist . Ich wünschte, das wäre Absicht. Das war zufällig. Das ist also so eine Art „Ich weiß, wie sich das anhört“, das Geräusch, das manche dieser Elektroautos machen, wenn sie langsam fahren. [Gelächter] Ja, ich denke schon. Ja. Willst du mir damit sagen, dass sie während der Fahrt Bluesmusik spielen ? Ähm , das ist also entgegen aller vernünftigen Definitionen der Blues für dieses spezielle Modell. Ich habe also auch über hinreichend und notwendig gesprochen. Wir hoffen also, dass es diesmal etwas besser ist. Ausreichend kann also wirklich, wirklich, wirklich klein sein. Denken Sie daran, dass das Modell das immer noch als Blues einstufen würde, selbst wenn es nur das Geräusch wäre, das wir gerade gehört haben. Das ist der Blues. Das ist das absolute Minimum. Minimum, ja. Okay, jetzt stellen wir uns also die Frage: Was ist hinreichend und was notwendig? Idealerweise würden wir uns wohl wünschen, dass es sich besser anhört, dass es mehr nach Blues klingt. Wenn wir uns das eigentliche Signal ansehen, ist es ziemlich faszinierend. Denken Sie also daran, dass wir Frequenzen aus ganz unterschiedlichen Bereichen des Frequenzspektrums entfernen. Für dieses einfache Experiment habe ich sie einfach auf Null gesetzt. Sie müssen sie nicht unbedingt auf Null setzen. Du kannst tun, was du willst, aber null erscheint vernünftig. Es geht im Grunde darum, diese Frequenz abzuschalten. Wenn wir es uns also genauer ansehen , sieht es tatsächlich ein bisschen so aus, als wäre es mit einer Backsteinmauer umgeben. Ich weiß nicht, ob Ihnen dieser Begriff bekannt ist. Anfang der 2000er Jahre, vielleicht sogar noch früher, gab es in der Musik eine Periode, die ich als die Klangkriege oder die Lautstärkekriege bezeichnete. Und alle mussten einfach immer lauter und lauter werden. Die Vorgehensweise ist also, dass man die wirklich lauten Stellen leiser macht und dann die leiseren Stellen lauter. Ähm, und am Ende sieht es ungefähr so ​​aus , alles ist gleich laut. Wir können uns das also anhören. Also, merkt euch: Das hier ist der Blues an sich. Und wenn ich das hier entferne, ist es nicht mehr der Blues. Was mir geblieben ist, ist nicht der Blues. Hören wir uns das also an. Und wir sind gespannt auf Ihre Meinung. [Musik] Das ist vernünftig, nicht wahr? Interessant, dass der Bass fehlt. Ja . Und ein Großteil des Schlagzeugs fehlt. Tatsächlich hält es in Wirklichkeit mein fantastisches Gitarrenspiel fest. [Gelächter] Also, ganz offensichtlich ist mein Gitarrenspiel Blues, was kein Kompliment ist, denn das Model ist auch der Meinung, dass das Blues ist. Also, hmm, da bin ich mir nicht so sicher . Okay, die letzte Frage, die wir uns stellen können, ist: Wenn wir dies von dem subtrahieren, bleibt dann noch genügend Signal übrig, um es an den Klassifikator zu senden? In diesem Fall ja . Das tun wir nicht immer. In diesem Fall schon. Und wir können fragen: Was ist es? Also, versuchen wir das einfach mal alleine. [Musik] Wo ist der Bass? Da ist der Bass. Also, die Musik und die Gitarre treten viel weniger in den Vordergrund, dafür das Schlagzeug viel stärker. Das ist also nicht der Blues. Was ist das? Okay, nun, wie würde man es klassifizieren? Ja . Sie haben 10 Optionen. Ich kann mich nicht an alle zehn erinnern, aber ich nenne euch Hip- Hop, Rock, Heavy Metal, Reggae und Pop. Sie haben fünf Auswahlmöglichkeiten. Sowas kommt vor . Meine äh, meine schlauen Hände sagen: Rock. Deine geschickten Hände werden erschossen und zu Klebstoff verarbeitet, fürchte ich. Äh, das wird als Hip-Hop eingestuft. Okay. Ähm, und ich kenne mich mit Hip-Hop tatsächlich nicht gut genug aus, um beurteilen zu können, ob das angemessen ist. Man könnte zwar sagen, dass es als Beispiel im Hip-Hop- Kontext verwendet werden könnte, aber ich denke, die meisten Leute würden zustimmen, dass das allein noch kein Hip- Hop ist. Das Modell sagt aber, dass es so ist. Was bedeutet das alles also? Das bedeutet, dass Ihr Modell, zumindest dieses Modell, in geschickten Händen ist. Und leider ist es nicht einmal besonders clever, denn eigentlich lässt es sich sehr leicht täuschen. Äh, wir haben ein ausreichendes Signal empfangen, das aber überhaupt nicht nach Blues klingt. Ich glaube, selbst wenn man taub wäre, würde man sagen, das ist nicht der Blues. Ähm, aber das Modell sagt, dass es so ist. Und noch schlimmer: Wir können den Blues aus dem Audio extrahieren und haben am Ende etwas übrig, das sich für mein Ohr zumindest immer noch irgendwie nach Blues anhört. Es ist grenzwertig. Ähm, aber das Model sagt, es sei jetzt Hip-Hop. Es wird nicht nur behauptet, es sei Hip-Hop, sondern es wird auch ganz klar gesagt, dass es sich um Hip- Hop handelt. Jedes Modell liefert Ihnen also zusätzlich zur Klassifizierung auch etwas, das wir üblicherweise als Konfidenz bezeichnen. Ob es sich dabei tatsächlich um einen Konfidenzwert handelt oder nicht, ist fraglich. Ähm, aber diese spezielle Audioaufnahme hat eine ziemlich hohe Punktzahl. Das war also mit 83%iger Wahrscheinlichkeit Hip-Hop. Und zumindest in diesem Raum sind wir uns nicht einig . Und das kann man mit so ziemlich jedem Modell machen. Ich habe hier ein Beispiel ausgewählt, weil es ein ziemlich extremes Beispiel ist, bei dem ich denke, dass das hinreichende Mindestens nicht wirklich zur Debatte steht. Ähm, aber ich habe das bei vielen, vielen Modellen ausprobiert und es funktioniert immer. Sie hören die Musik also nicht auf eine Weise, die ein Mensch verstehen würde. Sie führen lediglich eine Frequenzanalyse durch. Und manchmal lernen sie das Falsche . Sie betreiben Schnelllernen. Sie hören sich das also an und sagen: „Okay, das war der Blues. Wir sind fertig.“ Und ich spiele Ihnen noch etwas vor, das Sie vielleicht interessant finden werden. Was wäre, wenn ich unzählige ausreichende Signale nähme, hunderte davon, alle für den Blues, und sie addieren würde und die Frage stellen würde: „Ist das der Blues?“ Nun , ich habe es getan. Und es ist der Blues. Und ich spiele es dir jetzt vor. Denken Sie also daran: Hier wurden 100 ausreichende Signale miteinander vermischt. [Musik] Und das wird als Blues bezeichnet. Klingt nach [Musik], nach etwas, das man im Mutterleib hören könnte, oder ja. Ja, das stimmt. Ich habe das jemand anderem vorgespielt und der meinte, es klänge, als ob man draußen vor einem Zelt auf einem Festival wäre. Und vermutlich steht er unter Drogen. Ich bin mir nicht ganz sicher. Aber, ähm, nicht auf irgendeinem Festival, das ich besucht habe. Aber ich nehme an, der springende Punkt ist, dass diese Modelle funktionieren. Ich meine, die Genauigkeit dieses Modells ist sehr gut. Aber es funktioniert nicht so, wie ein Mensch es sich wünscht. Oder zumindest nicht auf eine Weise, die ein Mensch versteht. Ich halte das für eine berechtigte Behauptung. Sterns erste Untersuchung dieses Phänomens im Bereich der Musik liegt also 14 Jahre zurück, und er sagte: „Sehen Sie, diese Modelle, die ich teste. Das sind Pferde. Die verstehen keine Musik.“ Jetzt sind 14 Jahre vergangen und es ist kein bisschen besser geworden. Im Gegenteil, es ist wahrscheinlich noch schlimmer. Sie arbeiteten mit Finanzdaten oder Wetterdaten oder etwas Ähnlichem. Die Schwankungen von Minute zu Minute oder Stunde zu Stunde sind möglicherweise nicht von Bedeutung. Was Sie eigentlich wollen, ist eine gleichmäßigere Kurve. Okay? Wie würden Sie das anstellen? Rate mal, wie das geht. Es ist ein Durchschnittswert, nicht wahr? Einfach den Durchschnitt berechnen.