Transcript
Kai Ole Hartwig: Willkommen zurück zu Secrets Not Included, wieder mit Daniel und Ole hier.
Daniel Langemann: Vielen Dank.
Kai Ole Hartwig: Und in dieser Woche möchten wir mit euch über Policies reden.
Kai Ole Hartwig: Ich glaube, wir haben vor zwei oder drei Wochen das schon mal kurz angeschnitten, dass es da etwas gibt, was man nutzen kann, um ganz verschiedene Systeme abzusichern und zu prüfen, ob bestimmte Voraussetzungen eingehalten sind.
Kai Ole Hartwig: Und jetzt wollen wir diese Woche einfach etwas tiefer damit eingehen, reingehen mit euch.
Kai Ole Hartwig: Und zwar
Kai Ole Hartwig: in ein Tool, das nennt sich Open Policy Agent.
Kai Ole Hartwig: Das ist ein offizielles Projekt der Cloud Native Compute Foundation und nutzt eine eigene Policy Language, die Rego heißt.
Kai Ole Hartwig: Rego hatte ich da ja auch schon erwähnt.
Kai Ole Hartwig: Und ja, Daniel, ich glaube, du hattest letztes Mal Fragen dazu.
Daniel Langemann: Ganz viele, ich habe die immer noch.
Daniel Langemann: Ich muss ehrlich sagen... Oh, das ist schlimm, das kenne ich.
Kai Ole Hartwig: Ich hoffe, ich habe heute alle Antworten mit, nachdem ich mich auch wieder daran erinnere, wie wir das machen und mit welchem Tool.
Daniel Langemann: Dieses mit, es ist erledigt, Klick, Häkchen dran und aus dem Gehirn raus.
Kai Ole Hartwig: Ja, und wenn was ist, dann kann man ja nochmal, dann steht es in der Doku, was es war.
Daniel Langemann: Ja, genau.
Kai Ole Hartwig: Hervorragend.
Kai Ole Hartwig: Es ist in der Pipeline drin, in unseren Makefiles überall drin, wird ausgeführt.
Daniel Langemann: Also wir hatten über Policies gesprochen.
Daniel Langemann: Das Grundkonzept oder die Grundidee finde ich sehr interessant, dass man sagt, es gibt gewisse grundsätzliche Regeln.
Daniel Langemann: Fehler machen darf jeder, aber so Fehler zweimal, dreimal, viermal machen wird halt irgendwann peinlich.
Daniel Langemann: Gerade auch beim Kunden und
Daniel Langemann: das ist ja so der Grundgedanke gewesen, warum man angefangen hat zu testen.
Daniel Langemann: Man hat ja dann, oder meistens ist es so in einem Projekt mit, okay, es knallt, es geht irgendwas kaputt.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Ich als Entwickler sage, hm, habe ich nicht gesehen, aber ich baue den Test mit dem Fix zusammen, deploye das.
Daniel Langemann: Jetzt hast du von Policies gesprochen und das erzeugt bei mir natürlich eine Erwartungshaltung, dass ich sagen kann, guck mal, da könnte es etwas geben, wo ich mir Sachen zusammenbaue, Regeln zusammenbaue, auch
Daniel Langemann: jetzt nicht so konkret auf Business-Logik, die ein Projekt betrifft, aber wo man sagen könnte, es gibt immer wiederkehrende Fehler.
Daniel Langemann: Zum Beispiel, das weiß ich nicht, irgendwo Credentials landen, wo sie nicht hingehören, also eine.env-Datei, weil viele mittlerweile Angst haben, die zu committen, weil da jetzt Produktiv-Credentials drin landen oder so.
Kai Ole Hartwig: Und
Daniel Langemann: keine Ahnung, solche Sachen.
Daniel Langemann: Das triggert bei mir so etwas, wo ich sage, man könnte sich da einen Regelsatz aufbauen, um einfach, den man auch gerne teilt.
Daniel Langemann: Also wenn ich mal irgendwann einen habe, teile ich den gerne.
Daniel Langemann: Wo man sagt, das ist so ein Grundsetup mit, die Fehler hat schon mal jemand gemacht oder das ist schon mal schief gegangen.
Daniel Langemann: Ich bin safe, also zumindest was das betrifft, safe.
Kai Ole Hartwig: Ja, ich sag mal jetzt mal, das ist bei uns eine Mischung aus Komfort und es ist nervig, wenn man immer aufs gleiche Knie fällt, ne?
Daniel Langemann: Ist auch ein cooler Spruch, ja.
Kai Ole Hartwig: Also ich sag jetzt mal, wenn ich so an unsere Composer-Regeln denke, schauen wir da zum Beispiel, ist der Package-Key in der Form, wie wir ihn haben wollen oder auch für Typo3-Pakete, ist denn dieser Extension-Key da drin gesetzt?
Kai Ole Hartwig: Ja, ja.
Daniel Langemann: Achso, das ist wichtig für Typo 3.
Daniel Langemann: Das ist doch dann irgendwas mit Null-Pointer.
Kai Ole Hartwig: Ja, sonst kommt das System nicht damit klar.
Kai Ole Hartwig: Wenn dieser Extension Key fehlt, dann findet Typo3 das duft.
Kai Ole Hartwig: Das ist eine Regel, dass er halt da sein muss.
Kai Ole Hartwig: Und bevor man in diese komischen Fehler läuft, die das System dann schmeißt, weil es sagt dann ja nicht, hey, der Extension Key fehlt in dem Paket, das aber sagt, es ist ein Typo3-Paket, sondern du hast dann komische Fehlermeldungen und Seiteneffekte.
Kai Ole Hartwig: zumindest bis zum Zeitpunkt, wo wir diese Regel eingeführt haben, vielleicht ist es jetzt heute anders, nur wir laufen gar nicht mehr in dieses Sky, weil wir jetzt diese Regel da haben, ja, dann stand über mein Haupt, dass ich diesen Fehler wegen der Regel nicht mehr gemacht habe und jetzt ist alles voll super und das sagt mir, da fehlt der Extension Key.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Aber ich sage jetzt mal, ich bin ja nicht so lernfähig, immer morgens um vier oder so, wenn ich eine heiße Idee habe und anfange, was zu bauen.
Kai Ole Hartwig: vergessen.
Kai Ole Hartwig: Aber wir haben auch andere Regeln, zum Beispiel, dass die PHP-Version drinnen stehen muss.
Kai Ole Hartwig: Aus dem einfachen Gedanken, wenn wir nämlich Container bauen, schauen wir nämlich nach, hey, in dem Hauptprojekt, welche PHP-Version brauchen wir denn da?
Daniel Langemann: Oder wenn es leer wäre, nicht, ne?
Kai Ole Hartwig: Und das haben wir in der
Kai Ole Hartwig: Composer JSON gepflegt, weil sich dann unser Container quasi automatisch die richtige PHP-Version sieht, beziehungsweise unser Docker Setup halt auch lokal die richtige PHP-Version dann wieder bekommt.
Kai Ole Hartwig: Ja, also es ist halt total simpel, weil du dann halt über Variablen sehr flexibel und sehr zügig unterwegs bist mit dem Standard Setup.
Kai Ole Hartwig: Umso wichtiger ist natürlich, dass bestimmte Voraussetzungen für dich eingehalten sind.
Kai Ole Hartwig: Was wir auch noch machen, ist halt, wir prüfen halt dort Enddateien logischerweise, ob da so etwas drin steht wie Password, Secret, Key.
Daniel Langemann: Aber der...
Kai Ole Hartwig: Und ich glaube noch ein paar andere Dinge, die ich jetzt wieder mal nicht auswendig weiß.
Kai Ole Hartwig: Was steht da?
Kai Ole Hartwig: Ich kann es auf die Entfernung nicht lesen.
Kai Ole Hartwig: Ist zu klein.
Kai Ole Hartwig: Auf jeden Fall auch so Sachen, wenn irgendwo 1, 2, 3, 4 steht als Wert für irgendwas, dann finden wir das auch nicht cool.
Kai Ole Hartwig: Und dann sagen wir, na, sorry, not sorry, hier ist jetzt mal Schluss damit.
Kai Ole Hartwig: weil auch wenn wir.env-Dateien ja grundsätzlich nicht so mögen, haben wir halt trotzdem.env-Dateien.
Daniel Langemann: Ja.
Kai Ole Hartwig: Da sollen halt nur keine Secrets rein.
Kai Ole Hartwig: Die sollen bei uns, wenn sie denn existieren, eine Secrets.env, wo nur verschlüsselte Werte drin sind.
Kai Ole Hartwig: Da, wo wir SOPs einsetzen, ist das quasi der Weg,
Kai Ole Hartwig: Und dann prüfen wir halt entsprechend, sind dann alle Sachen, wo Secrets so von der Benahmung typischerweise drin wären, sind sie denn nur in der Datei und sind dann nur verschlüsselte Werte drin.
Daniel Langemann: Ja, je nachdem, welchen Algorithmus ich habe.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Du kannst ja nicht dann auch wieder sagen, okay, du weißt ja, womit der verschlüsselte String anfangen muss.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Und da prüfen wir dann drauf.
Kai Ole Hartwig: Und was wir auch machen,
Kai Ole Hartwig: ist, wir prüfen zum Beispiel, ob Lizenzen eingehalten werden.
Kai Ole Hartwig: Wenn du Open-Source-Pakete einsetzt, musst du natürlich darauf achten, oder solltest du eigentlich darauf achten, dass die Lizenzen, die du einsetzt, kompatibel sind und
Kai Ole Hartwig: dass die Lizenzen, die du in deinem Produkt drin hast, in deiner Plattform drin hast, auch zu dem Zweck passen.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Wenn du natürlich ein Paket ziehst, wo eine Lizenz drin ist, die sagt, naja, Commercial Use ist nicht erlaubt, erlaubt, wäre das für die meisten Projekte, die wir so haben, nicht unbedingt zuträglich.
Kai Ole Hartwig: um das jetzt vorsichtig auszudrücken.
Kai Ole Hartwig: Also das heißt, wir prüfen zum Beispiel darauf, ist da eine MIT oder Apache 2.0 oder ähnliche Lizenzen, GPL, in der entsprechenden Version drin, damit wir das ohne Probleme einsetzen können.
Kai Ole Hartwig: Und sonst muss man sich halt Alternativen suchen, ehrlicherweise.
Daniel Langemann: Und das geht dann so, dass der automatisch auch neue Pakete oder neue Abhängigkeiten mitprüft?
Kai Ole Hartwig: Ja, das kommt natürlich darauf an, wie du deine Regeln schreibst, ob das dann automatisch so klappt, aber wenn du halt sagst, okay, ich prüfe zum Beispiel die Package-JSON und die Composer-JSON, dann hast du zumindest einen guten Indikator dafür.
Daniel Langemann: Also das...
Daniel Langemann: Mhm.
Kai Ole Hartwig: Eigentlich musst du so Tools benutzen wie SPDX oder ähnliches, Lizenz-Scanner, die tatsächlich Datei für Datei durchgehen.
Kai Ole Hartwig: und da prüfen, was aber auch wieder zur Folge hat, dass du eigentlich in jeder Datei einen entsprechenden Eintrag haben musst oder eine Begleitdatei mit der Lizenz, weil die Lizenzscanner das sonst nicht sauber unterscheiden können und dann kommst du nämlich in das Problem, dass du sehr, sehr viele Unbekannte hast, die du manuell prüfen musst.
Daniel Langemann: Ja, das ist halt keine Hilfe.
Daniel Langemann: Aber das heißt ja eigentlich, dass sozusagen die Leute, die ihre Pakete pflegen und Open Source stellen, in der Composer JSON
Daniel Langemann: hoffentlich alle richtig, die Lizenz eintragen.
Daniel Langemann: Und da würde ich mich auch darauf verlassen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also erst mal, wenn es da Abweichungen gibt, ja, dann ist das halt, also ist das nicht so.
Daniel Langemann: Ist auch doof, aber mir wird das reichen für den Test, um mich darauf zu verlassen, zu sagen, guck mal, das Paket behauptet selber, es hat diese Lizenz.
Daniel Langemann: Wenn die sich jetzt da umentscheiden oder das irgendwann ändern, dann müssen die das da eintragen.
Daniel Langemann: Und ich denke mal, das werden auch 99 Prozent der Leute machen, wenn sie es nicht vergessen.
Kai Ole Hartwig: Ja, könnte sein, aus Erfahrung mit solchen Compliance-Prüfungen kann ich dir sagen, dass selbst große Open-Source-Pakete dich anlügen und nicht sauber die verwendeten Lizenzen deklarieren.
Daniel Langemann: Echt?
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Kai Ole Hartwig: Ja, dann gibt es dann irgendwo eine Binary oder ähnliches, nochmal tief vergraben, die aus einem anderen Paket kommt und eigentlich eine andere Lizenz hat.
Kai Ole Hartwig: Und das kann natürlich dann auf einmal kritisch werden, wenn das dann nicht kompatibel ist.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, genau, genau.
Daniel Langemann: Dass die Unterabhängigkeit sagt, dass es nicht kommerziell genutzt werden darf.
Daniel Langemann: Da hat jemand gepennt, hat die eingebunden und du bündest dann, oh Mann.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: So, und Compliance-rechtlich, ja, für alle Papiertiger da draußen, ist das natürlich ein riesiges Thema und ein Problem ist das auch lizenzrechtlich, ja, rein rechtlich betrachtet ist das natürlich total kritisch und verstößt halt gegen die Lizenzierung und die Bedingungen.
Kai Ole Hartwig: Jetzt sage ich aber im Alltag, wir müssen halt irgendwo die Kirche im Dorf lassen, das heißt, ich muss mich zu einem gewissen Teil darauf verlassen können,
Kai Ole Hartwig: Und mit dieser Regel prüfe ich zumindest mal, ob die Deklaration des Pakets so ist, dass ich davon ausgehen kann, dass alles richtig ist.
Daniel Langemann: Ja.
Kai Ole Hartwig: und muss nicht tausende Dateien, die keine saubere Deklarierung hatten, manuell durchgehen und prüfen.
Kai Ole Hartwig: Das ist dann etwas, das muss dann halt in Projekten speziell geprüft werden und speziell gemacht werden.
Kai Ole Hartwig: Das kann man dann halt nicht vollumfänglich automatisiert machen.
Kai Ole Hartwig: Und das Schöne ist an diesem OPA,
Kai Ole Hartwig: einem Open Policy Agent, dass du halt über die Tools hinweg prüfen kannst.
Kai Ole Hartwig: Du kannst halt nicht nur sagen, ich prüfe meine Composer JSON oder meine Package JSON oder jetzt irgendwelche PHP-Dateien, ob da jetzt Lizenzen drinstehen,
Daniel Langemann: Ja.
Daniel Langemann: Alles über 1024.
Kai Ole Hartwig: Sondern du kannst halt auch deine Dockerfiles prüfen, ob da jetzt ein Expose auf 80 stattfindet.
Kai Ole Hartwig: Oder du kannst halt auch Infrastruktur, Terraform-Sachen prüfen, ob da irgendwelche Einträge drin sind, die du nicht haben möchtest.
Kai Ole Hartwig: Wenn du zum Beispiel in einem OpenShift unterwegs bist, dass du nur Highport Expost, also sprich kein 80, kein 443, sondern halt irgendwo, ja,
Kai Ole Hartwig: Und damit kannst du halt sehr effektiv, sehr schnell prüfen, unabhängig von irgendeiner Programmier- oder deklarativen Sprache, die du einsetzt.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: sondern halt nur mit Rego als Sprache, die dann halt Policies insgesamt abbildet und dir die Sicherheit gibt, dass du es zum einen natürlich lokal ausführen kannst und prüfen in der Pipeline prüfen kannst und bestimmt auch noch an unterschiedlichen anderen Stellen das als Regeln einsetzt.
Kai Ole Hartwig: sodass du halt auch prüfen kannst, zum Beispiel wird immer vom root-user weggewechselt, ja, habe ich tatsächlich rootless-container, nicht nur mir ausgedacht, sondern sind die auch tatsächlich rootless-dich-einsätze.
Daniel Langemann: Ja.
Kai Ole Hartwig: Hat nicht jemand diese Regel entfernt am Tagesende?
Daniel Langemann: Ja, oder aus Versehen auskommentiert.
Daniel Langemann: Also ich muss ja zugeben, ich schaffe das auch immer wieder beim Entwickeln gerade mit, ich mache da kurz mal was weg und irgendwie zwei oder drei Ablankungen später weiß ich das nicht mehr.
Daniel Langemann: Und dann sind Sachen auskommentiert.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Gerade wenn ja die Container, die lokal laufen, die gleichen sind, die in Produktion laufen.
Kai Ole Hartwig: Wovon ich ein großer Fan bin.
Kai Ole Hartwig: So rein Debug-technisch und Fehleranfälligkeitsmäßig finde ich das immer sehr, sehr sympathisch, wenn ich quasi meinen Produktiv-Container habe und dann nochmal obendrauf eine Layer packe für Development mit DevTools.
Kai Ole Hartwig: Ähm, natürlich, wenn du dann den falschen Layer manipulierst oder manipulieren musst, weil irgendwas alles ist ganz seltsam.
Kai Ole Hartwig: Ähm, ja, manchmal ist es ja so, ne?
Daniel Langemann: Ich lache, weil ich das schon bestimmt zehnmal gemacht habe.
Daniel Langemann: Also nicht, weil ich besser bin, sondern weil das genau das ist, was ich auch mache.
Daniel Langemann: Also...
Kai Ole Hartwig: Irgendwie wird, dann muss man doch mal Ruth sein.
Kai Ole Hartwig: Und dann, ne, so.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Und man macht sich dann auch mal einfach Sachen kaputt.
Kai Ole Hartwig: Und damit man das dann halt wenigstens nachher nicht im Endergebnis drin hat im Repo, ist es natürlich total cool, wenn man die Regel hat, die einem sagt, jung, jetzt musst du noch mal ran.
Kai Ole Hartwig: Den Commit nehmen wir jetzt nicht an.
Daniel Langemann: Mm.
Kai Ole Hartwig: Und so sehe ich ja auch die Pipeline immer.
Kai Ole Hartwig: Meine Pipelines laufen ja immer von möglichst schnell und kosteneffektiv zu den teureren.
Kai Ole Hartwig: Also je früher es kaputt geht und sagt, da hast du aber Unfug gemacht.
Kai Ole Hartwig: je besser ist das, je schneller das geht.
Kai Ole Hartwig: Weil wenn am Ende es mir dann sagt, ja, aber jetzt, ich habe alles gebaut und jetzt stelle ich fest, du bist ja, dein Dockerfile ist ja auf einmal mit Hut.
Kai Ole Hartwig: Ja, danke, das wäre ein Fix von einer Sekunde gewesen gefühlt.
Kai Ole Hartwig: Also mach diese Regel mal zuerst und dann für bitte erst die Unit-Tests und so weiter und so fort aus.
Daniel Langemann: Ja, also ich finde das interessant.
Daniel Langemann: Zumindest, dass man, wenn ich es richtig verstanden habe, es gibt unterschiedliche Clients, glaube ich, womit man zum Beispiel auch JSON und andere Sachen lesen kann.
Kai Ole Hartwig: Ja, ich weiß nicht, ob das jetzt Client heißt, aber ja, es gibt, ja.
Daniel Langemann: Und dann...
Daniel Langemann: ich habe es gerade so genannt, also Implementierung, keine Ahnung, was es ist.
Daniel Langemann: Also die Möglichkeit, JSON-Dateien zu lesen oder JSON zu lesen und da auch darauf zu antworten oder beziehungsweise zu testen.
Daniel Langemann: Aber das basiert alles darauf, dass ich Regex eigentlich schreibe und sage, das ist das Ergebnis, ein Result-Set, wie auch immer, und darauf teste ich dann ein Regex.
Kai Ole Hartwig: Ja, nicht immer direkt ein komplettes Regex.
Kai Ole Hartwig: Du hast auch so Sachen, wo du sagen kannst, okay, jetzt der Anfang muss sein oder das Ende muss sein oder etwas muss lowercase sein oder uppercase und so.
Kai Ole Hartwig: Aber du kannst natürlich auch immer sagen, okay, Regex match und dann schreib dein Regex tag ein.
Daniel Langemann: Also man kann es entweder lesbar machen oder mit Regex machen.
Kai Ole Hartwig: Was war denn jetzt das Rek-Ax-Bashing?
Kai Ole Hartwig: Also ich mag Rek-Ax, also Rek-Ax hat mir echt schon manchen Tag gerettet.
Daniel Langemann: Und zehn Minuten später wusste ich nicht, was ich geschrieben habe.
Daniel Langemann: Ja.
Daniel Langemann: Ja, genau.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also wer es nicht kennt, Rek-Ax 101...
Kai Ole Hartwig: die Seite für Regex schreiben.
Kai Ole Hartwig: Ja, natürlich.
Kai Ole Hartwig: Manchmal verbringt man da zwei Stunden oder zumindest früher mal zwei Stunden, um das Regex, das beste Regex der Welt zu schreiben.
Kai Ole Hartwig: Dass man nach der Mittagspause auch, keine Ahnung, aber es funktionierte.
Kai Ole Hartwig: Ja, aber das ist halt bei Regex so.
Kai Ole Hartwig: Es ist
Daniel Langemann: Es ist super mächtig.
Daniel Langemann: Ich mag es sehr und ich kenne meine Schwäche.
Daniel Langemann: Ich übertreibe es gerne damit.
Daniel Langemann: Deswegen lache ich gerne darüber, dass man es entweder lesbar hat oder in Regex, weil irgendwann wird es einfach unlesbar.
Daniel Langemann: Wenn man das auseinandergefilmt hat, ist es aber super hilfreich manchmal, was man da unterbringen kann.
Kai Ole Hartwig: Ja, natürlich.
Kai Ole Hartwig: Aber du kannst in Rego nicht nur Regex nutzen.
Kai Ole Hartwig: Du kannst auch so Sachen sagen wie Not is empty und so.
Kai Ole Hartwig: Also ganz leserlich und einfach starten mit Regeln, schön immer in einzelner Dateien strukturieren.
Daniel Langemann: Aber das Grundkonzept, wenn ich das richtig verstehe, ist es, ich schreibe eine Reko-Datei, wo ich Annahmen treffe und sage, ich möchte, dass etwas Text enthält, nicht enthält, so formatiert ist, groß, kleinschreibt, also irgendwelche Regeln, kann dann sagen, das soll in dieser, dieser oder dieser Datei sein oder passieren oder enthalten sein.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Mehr Magie ist das gar nicht.
Kai Ole Hartwig: Also...
Daniel Langemann: Und das war's.
Daniel Langemann: Oder, also, dafür,
Daniel Langemann: Das ist viel zu einfach.
Daniel Langemann: Kann das nicht mehr Magie sein?
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich glaube, du kannst es auch auf unterschiedlichen Umgebungen ausführen.
Kai Ole Hartwig: Das machen wir jetzt zum Beispiel nicht.
Kai Ole Hartwig: Da kann ich jetzt nicht so richtig weiterhelfen.
Kai Ole Hartwig: Ich weiß, dass es auch in Kubernetes und Istio und so weiter läuft.
Kai Ole Hartwig: Und da bestimmt auch noch super fancy Sachen macht, die wir jetzt nicht so im Einsatz haben.
Kai Ole Hartwig: Aber wie es immer ist, irgendwo fängt man an, dann entdeckt man mehr Use Cases dafür, dann verwendet man das auf anderen Stellen.
Kai Ole Hartwig: Wir prüfen zum Beispiel auch, ob unsere Pipeline-Components entsprechend geschrieben sind und so Sachen, dass da bestimmte Sachen einfach drin sind.
Kai Ole Hartwig: Ich sage ja, man entdeckt halt immer mehr Möglichkeiten, wo man es einsetzen kann.
Kai Ole Hartwig: Je häufiger man irgendwo aufs Knie fällt und sagt, ach, das war jetzt aber mal wieder so ein richtig dummer Fehler, der überflüssig ist.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja genau, also dieses Projektunabhängige gefällt mir sehr.
Daniel Langemann: Also dass man, ne, weil alles was mit Tests, Unitests, Applikation, also alles was irgendwie testbar ist, ist immer projektspezifisch.
Daniel Langemann: das kann man schwer mitnehmen, sage ich mal, wo man sagt, das ist und oder unternehmensweit einführen für, ne, wenn du eine Agentur hast oder irgendwo ein großes Unternehmen und zig Projekte hast, kannst du ja schlecht irgendwie Unit-Tests von A nach B kopieren, also gibt es bestimmt auch, ne, dass du sich ein Test hier bildet.
Kai Ole Hartwig: ja, da sind die Unit-Tests halt auch das falsche Mittel.
Kai Ole Hartwig: Die Unit-Tests oder viele Testing-Sachen sind ja, ich sag mal, paketspezifisch.
Kai Ole Hartwig: Und damit kannst du halt ein allgemeines Set an Policies, an Regeln haben und verwenden.
Kai Ole Hartwig: Und das finde ich mega gut.
Kai Ole Hartwig: Das bedeutet halt, ich kann halt immer sagen, okay, pass auf, meine Enddatei, so, das möchte ich halt haben.
Daniel Langemann: Kannst du mal wieder auf die Finger hauen.
Kai Ole Hartwig: Und das Schöne ist,
Kai Ole Hartwig: damit erwischst du natürlich auch deinen KI-Agenten am Tagesende wieder, wenn er Schmuh macht.
Kai Ole Hartwig: Ja, der vergisst natürlich gerne, QS-Tools auszuführen zum Beispiel.
Kai Ole Hartwig: Ja, PHP-Stand, keine Ahnung, findet der mega ätzend, weil der natürlich immer die Fehler direkt aufdeckt.
Kai Ole Hartwig: Bei mir fängt der auch gerne an, dann zu meckern und zu sagen, ne, ne, ne, da sind schon wieder Fehler, aber die waren vorher schon da, das war ich gar nicht.
Daniel Langemann: Ja, ja, genau.
Daniel Langemann: Wie so ein Fünfjähriger, das war ich nicht.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, so, und das ist natürlich immer so mega ätzend.
Kai Ole Hartwig: Also, ganz ehrlich, ich erwarte, wenn ich der KI sage, hey, fix jetzt mal diese Fehler, da bitte mich interessiert diese Ausrede nicht mit, nee, die gab es schon vorher, mich interessiert nur, dass die Fehler weg sind.
Kai Ole Hartwig: Und wenn ich ein Tool habe, das halt blockiert und sagt, hier, da ist was falsch, dann kann die KI halt auch direkt darauf reagieren, indem ich sage, ja, jetzt, schau mal, wir haben das jetzt ausgeführt, das Tool, was du nicht machen wolltest.
Kai Ole Hartwig: Und die QS sagt jetzt halt, ist scheiße.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Jetzt beheb mal die Fehler, die hier drin stehen.
Kai Ole Hartwig: Ist mir egal, dass du sagst, du hast sie nicht gemacht, interessiert mich alles nicht, beheb einfach nur die Fehler.
Kai Ole Hartwig: Das ist ja genauso mit überall.
Kai Ole Hartwig: Ich sage jetzt mal, mich interessiert nie, wer einen Fehler gemacht hat oder wie dieser Fehler entstanden ist, sondern mich interessiert immer am Tagesende die Lösung und dass wir einen Fehler nicht häufiger machen.
Kai Ole Hartwig: Ja, wenn man jetzt einen Fehler zweimal gemacht hat, spätestens dann sollte man sich überlegen, wie stellen wir denn ab, dass es den wieder gibt.
Daniel Langemann: Ich habe auch keine Lust, einfach mehrfach zu erklären, dass es immer das Gleiche war.
Daniel Langemann: Tut mir leid, ich habe wieder nicht aufgepasst, das.
Kai Ole Hartwig: Ja, sorry, ich hatte noch nicht genug Kaffee.
Daniel Langemann: Hasse ich, wie die Pest, so etwas zu sagen.
Daniel Langemann: Ja, genau.
Daniel Langemann: Und also auf der anderen Seite, E-Commerce-Kontext zum Beispiel, kannst du den Kunden auch nicht erklären, dass alle drei Tage irgendwie das System weg ist, wenn die irgendwas auf ihre Wunschliste packen oder irgendwie eine komische Klickreinfolge nutzen und damit den Shop kaputt machen oder so, weil dann irgendwelche Abhängigkeiten in Datenbanken kaputt gehen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, oder dass ein Jobimport einfach mal zwei Wochen nicht funktioniert, weil man wieder mal was versemmelt hat oder dass Kontaktformulare nicht funktionieren oder Newsletter oder so, weil halt wieder irgendein, wenn man wieder den gleichen Fehler drin hatte oder einfach wieder auch Daten nicht richtig rübergekommen sind.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Das kannst du jetzt nicht damit validieren, aber dafür, das kann man ja auch abfangen, wenn man das erkennt.
Daniel Langemann: Ja, aber das ist ja auch wieder ein Baustein für das ganze Paket, sage ich mal.
Kai Ole Hartwig: Und
Daniel Langemann: Genauso wie Unit-Tests, Applikationstests oder Integrationstests und Applikationstests ihre Berechtigung und ganz andere Ziele haben, finde ich das mit den Policies gar nicht mal falsch, weil das ist halt wieder ein Teil, den die anderen drei jetzt nicht abdecken, wo du sagen kannst, das ist halt wieder ein Stückchen besser.
Kai Ole Hartwig: Und ich finde, es ist halt auch eigentlich eine mega hilfreiche Policy und ich finde es immer peinlich, wenn andere Dienstleister das nicht auf die Kette kriegen, wenn sie Sachen übernehmen.
Daniel Langemann: Am besten so im CC-Benz.
Kai Ole Hartwig: dass dann mal keine alten E-Mail-Adressen da mehr drinstehen.
Kai Ole Hartwig: Ja, weil ich kann ja super leicht darauf filtern, ist diese Domain jetzt in einem Kontext eines Kommentars oder ist das eine scharfe Adresse, wo Sachen hingeschickt werden.
Kai Ole Hartwig: Das ist nämlich immer total cool, finde ich, wenn dann ein Dienstleister was übernimmt, man Sachen abgibt, whatever.
Daniel Langemann: Vielen Dank.
Kai Ole Hartwig: Und dann bekommt man auf einmal Monate später tausende Fehler-E-Mails von einem System geschickt, weil mal wieder jemand vercheckt hat, ganz einfach diese Konfiguration zu ändern.
Kai Ole Hartwig: Oder auch so was wie so ein Sentry, dann auf einmal Fehlermeldungen von so einem URL-System auf einmal geschickt bekommt oder error-tracking in GitLab, weil man einfach diese Einträge nicht ändert.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und wir haben zum Beispiel auch dann halt Regeln, die prüfen, jetzt sind alle scharfen E-Mail-Adressen denn von uns.
Kai Ole Hartwig: So, ja.
Kai Ole Hartwig: Und gibt es so was wie diese DSN, wo Fehler hingeschickt werden?
Kai Ole Hartwig: Und wenn ja, stimmt denn die Domain mit der erwarteten Domain überein?
Daniel Langemann: Ja, das ist natürlich geil, wenn du eine Agentur hast und dann kannst du sowas mitnehmen und dann, wenn du ein neues Projekt mitnimmst, lässt du es einfach drüber laufen und da muss sich kein Entwickler wieder drei Stunden hinsetzen und per Grab irgendwie sich dadurch einen frischen Quelltext begraben.
Daniel Langemann: Das spart Zeit.
Kai Ole Hartwig: Ja, so.
Kai Ole Hartwig: Also, macht dich halt als neuen Dienstleister total glücklich.
Kai Ole Hartwig: Ja, weil, weil halt du auch professioneller auftreten kannst und nicht irgendwie der alte Dienstleister da ständig ankommt und sagt, ey, Freunde, ihr schickt uns immer noch Fehlermeldungen, was soll der Scheiß?
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Na?
Kai Ole Hartwig: Und du stellst halt auch sicher, dass du halt direkt alles bekommst.
Kai Ole Hartwig: Wie fantastisch ist das denn, wenn du quasi deinem Kunden zeigst, hey, ich kann das auch, was ich tue?
Kai Ole Hartwig: Ja, so, aber aus der Erfahrung heraus kann ich sagen, das ist nicht die Masche, die alle Dienstleister fahren.
Daniel Langemann: Das ist natürlich schade, weil alleine die Zeit, die du dir sparst mit solchen Sachen.
Daniel Langemann: Also ich denke mal, der erste Wurf wird gar nicht so besonders sein, wenn man mit sowas anfängt, aber ich glaube, über die Jahre oder über das Jahr, dass man da echt ein gutes Regelset aufgebaut bekommt.
Kai Ole Hartwig: Ja, und du musst es halt nicht direkt in LMM schmeißen, also du musst es nicht in die KI schmeißen, sondern du kannst halt echt Low-Level mit wenig Energieeinsatz sehr, sehr viel erreichen.
Daniel Langemann: Hängt halt ein bisschen davon... Hm.
Kai Ole Hartwig: Klar, die KI kannst du nutzen, um dir fremden Quellcode erklären zu lassen und so weiter und so fort.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Da kannst du auch sicherlich sagen, sind da irgendwelche E-Mail-Adressen noch drin geschenkt?
Kai Ole Hartwig: Das geht alles.
Kai Ole Hartwig: Ja, wer KI dafür nutzen will, go for it.
Kai Ole Hartwig: Das ist halt quasi die umweltfreundliche Alternative.
Daniel Langemann: Green Coding, ja.
Kai Ole Hartwig: Ja, man könnte ja darüber nachdenken, dass es cool ist, wenig Energie für so Aufgaben einzusetzen.
Daniel Langemann: Ich würde einfach nicht so viele Tokens verschwenden wollen dafür.
Daniel Langemann: Ich verbrauche die für andere Sachen.
Daniel Langemann: Also das ist in meinen Augen verschwendet, weil für andere Sachen sind sie definitiv sinnvoller eingesetzt einfach.
Kai Ole Hartwig: Ja, natürlich, aber auch das
Daniel Langemann: Und gerade wenn andere in Tropic und so anfangen, die zu beschränken und versuchen, so die außerhalb der Zeiten dich zu motivieren, die Modelle zu nutzen, dann merkst du schon, wo die Reise hingehen wird in Zukunft.
Kai Ole Hartwig: ja immer schon zwischen Mitternacht und 6 Uhr arbeiten.
Daniel Langemann: Mhm.
Daniel Langemann: Da merkst du, wo die Reise in Zukunft hingehen wird.
Daniel Langemann: Also das ist natürlich, dass die Token, die müssen entweder besser werden, die Modelle, dass das günstiger für Entropic und andere wird, oder es wird teurer.
Daniel Langemann: Und bei weitem ist Geld.
Kai Ole Hartwig: Nee, die Frage ist halt, möchte man nicht eh auf ganz andere Modelle wechseln, ne?
Daniel Langemann: Mhm.
Kai Ole Hartwig: So ein Modell, das ich gerade teste, schleifen wir total ab, aber macht nix.
Kai Ole Hartwig: Das ist Gamma 4.
Kai Ole Hartwig: Ja, ich finde, das ist extrem vielversprechend und ich bin auch immer noch ein großer Fan von DevStral, von europäischen Modellen allgemein.
Daniel Langemann: Hoffentlich.
Kai Ole Hartwig: Ich finde, der Unterschied ist nicht so groß, dass man jetzt sagen müsste, ich muss unbedingt Cloud Code nutzen.
Daniel Langemann: Ich muss zugeben, ich habe sie noch nicht ausgiebig genutzt.
Daniel Langemann: Also, weil wäre interessant, wie du das aufgesetzt hast.
Daniel Langemann: Also, ich habe jetzt zum Beispiel ein MacBook.
Daniel Langemann: Ich müsste mir was Größeres mit mehr Arbeitsspeicher kaufen.
Daniel Langemann: Ich habe zwar so eine kleine Datenkrücke, nenne ich sie immer, aber die hat weniger Arbeitsspeicher als mein MacBook, weil die einfach nur besseres Nass ist.
Kai Ole Hartwig: Ich habe halt auch ein altes MacBook, das so M1-Chip und da probiere ich dann halt Sachen drauf aus, ne?
Daniel Langemann: Mhm.
Kai Ole Hartwig: Der hebt dann, also, ne, das fungiert auch gleichzeitig als Heizung.
Daniel Langemann: Also ich hatte es einmal ausprobiert und ich war überrascht, dass mein MacBook einen Lüfter hat.
Daniel Langemann: Ich hatte den vorher noch nicht gehört.
Daniel Langemann: Griffheizung für Motorradfahrer, für Entwickler, ja.
Kai Ole Hartwig: Ja, iMacs haben auch Lüfter, habe ich dabei rausgefunden.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Bei Amex ist es eigentlich ganz praktisch.
Kai Ole Hartwig: Dann hast du so einen warmen Luftfilm auf den Händen.
Kai Ole Hartwig: Das ist eigentlich ganz angenehm.
Kai Ole Hartwig: Also, im Winter ist das... Ja, ja.
Kai Ole Hartwig: Tatsächlich finde ich, die Modelle werden ja auch kleiner und leistungsstärker.
Daniel Langemann: Mm.
Kai Ole Hartwig: Und du merkst, oder ich merke in vielen Aufgaben keinen signifikanten Unterschied.
Kai Ole Hartwig: Also die Code-Qualität kann bei Cloud genauso daneben liegen wie bei DevStraw.
Kai Ole Hartwig: Und je nachdem, was ich mache, merkst du halt den Unterschied nicht.
Kai Ole Hartwig: Wenn du gerade so ganz neue Pakete nimmst und Sprachversion und Paketversion, da ist kein Unterschied in der Qualität.
Kai Ole Hartwig: Die ist gleich schlecht übrigens bei allen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, oder du brauchst die gleichen Voraussetzungen, glaube ich, dafür.
Daniel Langemann: Nicht viel, aber du brauchst Tooling drumherum, um gewisse Sachen festzulegen, so ein bisschen die Leitplanken zu definieren und dann viel auf die Finger kloppen, damit PHP-Stand doch ausgeführt wird und nicht ignoriert wird.
Daniel Langemann: Bei mir war sie immer sehr kreativ und meinte so, ich kann das nicht lösen, der Test ist falsch, ich muss den Test anpassen.
Daniel Langemann: Ich habe immer gedacht, nein, der ist genau richtig.
Daniel Langemann: Lass ihn so.
Daniel Langemann: Hm.
Kai Ole Hartwig: Ja, also, es gibt ja auch die Möglichkeiten, Hoax-Plugins und so weiter einzubinden und da die Systeme in die richtige Richtung zu zwingen.
Kai Ole Hartwig: Alles tausend Möglichkeiten.
Kai Ole Hartwig: So ist es ja nun nicht, dass man das jetzt nicht machen könnte.
Kai Ole Hartwig: Aber das Kernergebnis, ja, ich sag mal, das, was beim ersten Durchlauf rausfällt, ähm,
Kai Ole Hartwig: Da wäre es ja schön, wenn schon möglichst hohe Qualität da ist.
Kai Ole Hartwig: Dass sich das an so Kleinigkeiten erinnert wie in, naja, schau mal, in der Paketversion, da gibt es diese Funktion einfach gar nicht mehr.
Kai Ole Hartwig: Weil, klar, wenn er dann sagt, ah, ich linde jetzt das PHP, da ist kein Fehler drin und so weiter und so fort, dann landet er irgendwann bei PHPStan und PHPStan sagt, das ist aber Unfug.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Ja, dann hat man das natürlich verhindert und abgefangen.
Kai Ole Hartwig: Aber wäre ja schlau, wenn sich die KI einfach so sagt, okay, ich habe jetzt diese Dependency gelesen, ich habe sie verstanden und jetzt setze ich sie auch vollständig so ein und nicht sage, ah, in meinen Trainingsdaten, da gab es aber das.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: die sind halt nicht aktuell.
Daniel Langemann: Und das merkt man.
Daniel Langemann: Also wenn man an zu neuen Versionen dran ist, sind Sachen einfach nicht da.
Daniel Langemann: Die Trainingsdaten sind nicht aktuell.
Daniel Langemann: Das ist nicht hilfreich.
Daniel Langemann: Aber grundlegend ist es ja auch so, man sollte KI ja eigentlich nicht dafür nutzen,
Daniel Langemann: Sachen zu generieren, weil sie nicht deterministisch ist, sondern maximal dazu nutzen, sich Tools und Programme zu bauen, die deterministisch sind.
Daniel Langemann: Also bei uns beim Programmieren ist es nochmal etwas besonders.
Daniel Langemann: Aber so mein Lieblingsbeispiel ist immer, du kannst der KI sagen, bitte rechne mir mal diese Excel-Tabelle aus.
Daniel Langemann: Oder kannst dir sagen, bauen wir ein Python-Script, was alle Excel-Tabellen aus diesem Ordner nimmt und daraus Summen bildet.
Kai Ole Hartwig: Ja, definitiv.
Daniel Langemann: Und der gleiche Gedanke ist ja beim Programmieren auch so ein bisschen.
Daniel Langemann: Dieses, wenn ich sage, mach das mal oder grade das mal ab, dann funktioniert das nicht so.
Daniel Langemann: Wenn du aber sagst, ich habe Rektor im Projekt und ich möchte diese Sachen machen, gibt es da Regeln für?
Daniel Langemann: Dann spuckt die dir ganz schnell Sachen aus oder hilft dir zum Beispiel auch Custom-Regeln zu bauen, um dann Rektor über das Projekt laufen zu lassen.
Daniel Langemann: Also... Hm...
Kai Ole Hartwig: Also das ist immer die Frage, welchen Weg geht man und wie sagt man es?
Kai Ole Hartwig: Also es ist
Kai Ole Hartwig: Vibe Coding, oder es ist Agentic Engineering.
Kai Ole Hartwig: Und was ich ganz cool finde bei Mistral, ich habe es ehrlicherweise noch nicht ausprobiert, komplett ist, aber kannst du auch einfach für deine Cloud Feintuning der Modelle machen.
Daniel Langemann: Das hört sich wieder klug an.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Kai Ole Hartwig: Wenn du halt weißt, ich nutze jetzt die PHP 8 und ich sage jetzt mal Typo 3 14, also 14.2, dann kannst du das Feintuning auf das Modell machen damit.
Kai Ole Hartwig: Und dann kennt das Modell das und dann sind deine Ergebnisse direkt anders.
Daniel Langemann: Das ist ein Thema, ich glaube, da müssen wir mal wieder eine eigene Folge drüber machen.
Kai Ole Hartwig: Naja, bisher habe ich Feintuning auch nur lokal gemacht.
Daniel Langemann: Live-Coding, oh mein Gott.
Kai Ole Hartwig: Also, aber ja, eine eigene Folge ist eine gute Idee.
Kai Ole Hartwig: Da können wir dann auch zwei, drei Tage drüber reden.
Kai Ole Hartwig: Wir machen das dann als Livestream bei YouTube direkt oder so.
Daniel Langemann: Aber das muss FSK 18 sein.
Daniel Langemann: Also die Schimpfwörter, die da fliegen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Aber das ist tatsächlich ein sehr großes Thema.
Kai Ole Hartwig: Wie geht man damit gut um?
Kai Ole Hartwig: Was kann man machen?
Kai Ole Hartwig: Vielleicht machen wir dafür wirklich mal ein paar eigene Sessions.
Kai Ole Hartwig: Das entwickelt sich ja auch ständig weiter.
Kai Ole Hartwig: Was ich heute sage, ist morgen ja schon wieder veraltet.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, aber auch die Idee, die wir vorhin hatten mit Agent im Docker-Container und Zugriff reduzieren, das will ich mir nachher mal angucken oder würde ich gerne mal weiter ausprobieren.
Daniel Langemann: Vielleicht hat man da etwas, worüber man auch noch erzählen kann.
Daniel Langemann: Und dann passt das ja sehr gut zusammen, weil wenn du das im Docker-Container hast, kannst du den auch deployen zum Beispiel oder auch feintunen auf deine besonderen Anforderungen.
Kai Ole Hartwig: Ja, wobei Feintuning im Docker-Container ist, glaube ich, keine gute Idee.
Daniel Langemann: Also mache ich es, ja.
Kai Ole Hartwig: Was auch keine gute Idee ist, kann ich dir schon verraten, dem Container keinen Zugriff aufs Internet zu geben.
Kai Ole Hartwig: Weil dann kann er auch so Dinge wie Context 7 nicht abrufen.
Kai Ole Hartwig: Das macht dann Ergebnisse noch schlechter.
Kai Ole Hartwig: Ja, also das ist ja gerade die Krux mit den Tools.
Kai Ole Hartwig: Du musst denen halt irgendwie dafür, dass sie gut funktionieren, musst du ihnen halt viele Rechte geben, wie bei so einem echten Entwickler.
Kai Ole Hartwig: Wenn du einen echten Entwickler ohne Internet irgendwo einsperrst, dann werden die wenigsten in kurzer Zeit richtig gute Ergebnisse produzieren.
Kai Ole Hartwig: Ja, wir schreiben halt alle nicht wie früher den Code auf Papier oder so und überlegen uns vorher, welche Fehler passieren, sondern wir sind ja sehr, wir machen mal und schauen mal getrieben und wir schauen mal nach.
Kai Ole Hartwig: Das ist ja nicht mehr wie bei der letzten Mondlandung.
Daniel Langemann: Ja, du kannst auch nicht alles wissen.
Daniel Langemann: und.
Kai Ole Hartwig: So, und wir machen keine Raketenwissenschaft.
Kai Ole Hartwig: Sagt auch Outlook, das zum Mond fliegt.
Daniel Langemann: Aber manchmal machen wir daraus eine.
Kai Ole Hartwig: Oder das MPM-Paket, das auch das Dashboard für SpaceX ist.
Kai Ole Hartwig: Aber es läuft sogar in Chrome, wenn ich mich richtig erinnere.
Kai Ole Hartwig: Ja.
Daniel Langemann: Jungs, warum musstet ihr zwei Gigabyte Note-Modules deployen?
Daniel Langemann: Wir brauchten nur ein Dashboard.
Daniel Langemann: Hm.
Kai Ole Hartwig: Aber es ist ja tatsächlich jetzt...
Kai Ole Hartwig: ist es ja fast schon wirklich egal geworden, weil einfach die Speichermengen so verfügbar sind heute und auch die Datenübertragungsmengen.
Kai Ole Hartwig: Also ich meine, wir können gerade von der aktuellen Mondmission HD YouTube Livestreaming sehen.
Kai Ole Hartwig: Ja, weil einfach mit einem fucking Laserstrahl die Daten übertragen werden.
Kai Ole Hartwig: Mein Sohn hat dazu gestern Abend so schön gesagt, Glasfaser im Weltraum.
Kai Ole Hartwig: Ich
Daniel Langemann: Das ist echt geil beschrieben.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: So, ich fand, das war die treffendste Beschreibung für das, was da eigentlich gerade gemacht wird, so ein bisschen.
Kai Ole Hartwig: Und überleg mal, wir bekommen es nicht mal hin, Glasfaser im Boden hier auf der Erde zu verwenden in Deutschland, flächendeckend, aber wir schicken 4K-Videos durchs Weltall als Livestream.
Daniel Langemann: Also ich muss da jetzt die Telekom bashen.
Daniel Langemann: Stefanie, die hätten Probleme.
Daniel Langemann: Techniker kommt zwischen 8 und 18 Uhr, um das Kabel anzuschließen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Peace.
Daniel Langemann: Wir mögen auch die Telekom.
Daniel Langemann: Also wenn wir gesponsert werden.
Kai Ole Hartwig: Ja, ja.
Kai Ole Hartwig: Unfassbar.
Kai Ole Hartwig: Gut.
Kai Ole Hartwig: Ich glaube, dann...
Kai Ole Hartwig: war es diese Woche eine wunderbare Secrets Not Included Folge mit Glasfasern-Weltalp-Policies und KI-Modellen, die vielleicht im Container laufen.
Daniel Langemann: Sehr kreativ waren wir ja.
Daniel Langemann: Bis dann, ciao.
Kai Ole Hartwig: Ja, hervorragend.
Kai Ole Hartwig: Dann sehen wir uns nächste Woche wieder mit einer noch viel besseren, neuen Folge Secrets Not Included.
Kai Ole Hartwig: Wenn ihr die nicht verpassen wollt, folgt uns, teilt es, gebt uns einen Daumen hoch, 5 Sterne oder whatever.
Kai Ole Hartwig: Und bis dahin, macht's gut.
Kai Ole Hartwig: Ciao.
