1021 | Warnstufe Rot: Sicherheit, KI und die Wackelnde Digitale Welt

Lena Vogel: Hallo und willkommen zurück beim Podcast! Ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Schön, dass du wieder dabei bist. Heute schauen wir auf einen Haufen Geschichten, die auf den ersten Blick nichts miteinander zu tun haben – aber wenn man genauer hinschaut, geht es in fast allen um dieselbe Frage: Wie viel Vertrauen können wir eigentlich in die Systeme setzen, auf denen unser Alltag aufbaut? Server, Zertifikate, Cloud-Anbieter, Wissensplattformen, Software, Bildschirme.

Lena Vogel: Genau. Wir fangen heute mit einem richtig ernsten Sicherheitsthema an, weil da seit gestern extrem viel Bewegung drin ist, und dann arbeiten wir uns durch Cloud, KI, Entwickler-Werkzeuge, den digitalen Alltag und am Ende noch ein paar ganz menschliche Geschichten. Los geht's mit PHP.

Felix Hartmann: Also, die Neuigkeit selbst ist kurz erzählt, aber die Sprengkraft ist groß. Das PHP-Team hat vorab gewarnt: Am 21. Oktober 2026, um 14 Uhr UTC, kommt ein Security-Release. Und das ist nicht irgendein Patchday – es geht um zwei kritische Schwachstellen mit einem CVSS-Score von 9,2. Das ist quasi das obere Ende der Skala.

Lena Vogel: Und betroffen sind nicht nur die aktuellen Versionen. Die Warnung geht bis PHP 5 zurück. Das heißt, alle Versionen von PHP 5 bis 8 haben das Problem. Das ist ein enorm breiter Zeitraum – da hängen unzählige alte Anwendungen dran, alte CMS-Systeme, alte interne Tools, Dinge, die irgendwo in der Ecke eines Rechenzentrums laufen und seit Jahren niemand mehr angefasst hat.

Felix Hartmann: Und genau da liegt ja der Knackpunkt, den die Leute im Thread auch immer wieder gemacht haben: Vorab-Warnungen mit konkretem Uhrzeit-Stempel sind fast immer ein Zeichen dafür, dass es hier um etwas geht, was aktiv ausgenutzt werden könnte. Man will den Betreibern Zeit geben, vorbereitet zu sein, bevor die Details öffentlich werden. Denn sobald der Patch draußen ist, kann ja jeder den Diff lesen und die Lücke nachbauen.

Lena Vogel: Was ich spannend finde, ist die Notfall-Mitigation, die mitgeliefert wurde: session.upload_progress deaktivieren. Das ist eine PHP-Konfigurationsoption, die eigentlich eine relativ unscheinbare Funktion abdeckt – sie erlaubt es, den Fortschritt von Uploads zu tracken, etwa für diese Fortschrittsbalken beim Datei-Upload. Wer das in der php.ini auf "off" setzt, hat offenbar einen wirksamen Schutz, bis der Patch kommt.

Felix Hartmann: Und das erklärt der Community ja einiges. Erstens: Es ist eine Mitigation, die fast jeder anwenden kann, ohne den Code anzufassen. Man muss nur an die Konfiguration ran. Das ist der Unterschied zwischen "wir müssen die Anwendung umschreiben" und "wir ändern eine Zeile in einer Config". Zweitens sagt uns diese Mitigation indirekt etwas darüber, wo die Lücke ungefähr sitzt – nämlich im Umfeld von Uploads und Sessions.

Felix Hartmann: Mehr wird nicht offiziell gesagt, aber das ist eben so eine typische Form von angemessener Vorteilhaftigkeit: genug Info zum Handeln, nicht genug Info zum Ausnutzen.

Lena Vogel: Es gibt trotzdem Kritik an dem Verfahren. Einige Kommentatoren fanden es problematisch, dass eine so konkrete Mitigation schon vor dem Release rausgeht – weil man daraus eben doch Rückschlüsse ziehen kann. Andere haben das Gegenteil argumentiert: Wenn kritische Lücken mit CVSS 9,2 in der Wildnis sein könnten, dann ist jedes Tag ohne Mitigation ein verlorenes Tag. Diese Spannung kennt man aus jederDisclosure-Debatte: koordinierte Disclosure versus sofortige Transparenz.

Felix Hartmann: Das eigentliche ungelöste Problem ist aber die Basis. Wie viele Systeme weltweit laufen auf PHP-Versionen, die gar nicht mehr gepflegt werden, auf shared Hosting, wo niemand die php.ini anfassen kann? Die Warnung erreicht die Profis sofort. DieBetreiber dieser zehnjährigen Vereins-Website erreichen sie vielleicht nie. Das ist bei jedem breiten PHP-Loch so, aber bei einem Score von 9,2 über fünf Major-Versionen ist es eben besonders relevant.

Lena Vogel: Und was man noch fair sagen muss: Es ist unbekannt, wie groß der tatsächliche Schaden ist – ob das schon ausgenutzt wird, wie viele Systeme tatsächlich verwundbar und erreichbar sind. Das wird sich erst nach dem 21. Oktober zeigen. Wer PHP betreibt, sollte sich jetzt schon die Frage stellen: Kann ich das Patchfenster wahrnehmen, und kann ich vorher die Mitigation ziehen?

Felix Hartmann: Und genau da schließt sich der Kreis zu einem anderen Infrastruktur-Thema von gestern, das in dieselbe Kategorie fällt: Zertifikate. Da hat der Anbieter eMudhra gemeldet, dass private Schlüssel von acht Intermediate-CAs kompromittiert wurden.

Lena Vogel: Kurz für alle, die den Begriff nicht jeden Tag benutzen: Eine Intermediate-CA ist eine Zwischenstelle in der Zertifikatshierarchie. Die Root-CA signiert Intermediate-Zertifikate, und die Intermediate signieren dann die eigentlichen TLS-Zertifikate von Webseiten. Wenn ein Angreifer an den privaten Schlüssel einer Intermediate kommt, kann er im Prinzip gültig aussehende Zertifikate für beliebige Domains ausstellen. Das ist der Alptraum-Szenario im Web-PKI.

Felix Hartmann: Die Reaktion war entsprechend schnell und systematisch. Browser und Betriebssysteme haben die betroffenen Intermediate-Zertifikate zwischen dem 17. und 20. Oktober blockiert. Das heißt, Zertifikate, die über diese Zwischenstellen ausgestellt wurden, werden nicht mehr als vertrauenswürdig behandelt.

Lena Vogel: Der Punkt, der im Thread am meisten Diskussion ausgelöst hat, ist die zweite Welle der Reaktion: Programmiersprachen-Pakete. Go, Rust und Python vertreiben ja teilweise eigene Root-Trust-Stores oder ziehen sie aus den Systemen – und die mussten selbst Updates bekommen. Das zeigt etwas Wichtiges: Das Vertrauenssystem des Webs liegt nicht nur bei den Browsern. Es ist in zig Sprachen, Bibliotheken und Tools kopiert, und jedes davon ist eine eigene Instanz, die auf so einen Vorfall reagieren muss.

Felix Hartmann: Und die Geschwindigkeit ist unterschiedlich. Browser-Updates rollen automatisch. Aber ein Python-Paket in einer CI-Pipeline oder ein Go-Tool auf einem Server – das updated nur, wenn jemand es updated. Da gibt es eine echte Lücke zwischen "der Vorfall ist offiziell behoben" und "jede einzelne Maschine hat den neuen Trust-Store". Die Kommentatoren haben da einstimmig darauf hingewiesen, dass hier potenziell wochenlang alte Zustände in Produktion laufen.

Lena Vogel: Ungelöst bleibt auch hier die Schadenshöhe: Wurden tatsächlich Fälschungszertifikate ausgestellt? Für welche Domains? Das ist zum Zeitpunkt unserer Aufnahme nicht öffentlich. Was bleibt, ist eine seltsame Gemengelage: eMudhra ist ein etablierter Anbieter, und trotzdem passierte das – man kann sich vorstellen, wie es kleinen CAs geht.

Felix Hartmann: Und jetzt das dritte Stück im Infrastruktur-Puzzle, das ist die vielleicht gruseligste Geschichte der drei: kompromittierte Tor-Exit-Nodes. Da hat ein Autor berichtet, dass er 333 Tor-Exit-Nodes identifiziert hat, die kompromittiert waren – das sind laut seinen Zahlen rund zehn Prozent aller Exit-Nodes.

Lena Vogel: Zehn Prozent. Das ist eine Zahl, die einen erst mal schwindelig macht. Was haben die Nodes gemacht? Sie haben SSH-Verbindungen abgefangen. SSH – also das Protokoll, mit dem Admins auf ihre Server zugreifen. Wenn dein SSH-Verkehr durch einen kompromittierten Exit-Node läuft, kann der Betreiber des Nodes essentially einen Man-in-the-Middle machen.

Felix Hartmann: Und die Payload ist identifiziert: Es ist die Ebury-Backdoor. Das ist eine Malware-Familie, die es schon seit vielen Jahren gibt und die Server infiziert, um sie zu kontrollieren. Die kompromittierten Nodes haben also versucht, Ebury in SSH-Verbindungen einzuschleusen – vermutlich, indem sie manipulierte SSH-Server-Antworten oder Downloads unterschoben.

Lena Vogel: Was viele im Thread als Erklärung herangezogen haben: SSH-Public-Key-Verifikation funktioniert nur, wenn der Client den Server-Fingerprint schon kennt und den Vergleich Ernst nimmt. Beim ersten Verbinden ist man verwundbar, und auch bei manchen automatisierten Prozessen wird die Verifikation lax gehandhabt.

Lena Vogel: Der Tor-Exit-Node ist dabei der perfekte Ort, weil er genau auf dem Pfad zwischen dir und deinem Ziel liegt – und Tor die Verbindung zwar verschlüsselt, aber der Exit-Node ist per Definition der Endpunkt der Tor-Verschlüsselung.

Felix Hartmann: Gute Nachricht am Ende: Es gab einen Takedown durch das Tor-Team selbst. Die kompromittierten Nodes wurden aus dem Netzwerk entfernt. Das ist ein relativ ungewöhnlich direktes Eingreifen, und es zeigt, dass die Tor-Organisation solche Fälle ernst nimmt und handlungsfähig ist.

Lena Vogel: Die offenen Fragen sind aber dieselben wie bei PHP und eMudhra: Wie viele Admins sind durch die Abfangversuche tatsächlich infiziert worden? Die 333 Nodes sind die Verteil-Infrastruktur, nicht der Schaden selbst. Wer hat wann über welche Nodes verbunden? Das lässt sich nachträglich kaum rekonstruieren.

Felix Hartmann: Man kann die drei Geschichten wirklich als eine Lektion lesen: Die Grundschichten – PHP-Interpreter, Zertifikatskette, Anonymisierungsschicht – sind alle verwundbar, und der Schaden ist jeweils unsichtbar, bis jemand hinschaut. Und wenn Server streiken oder wegfallen, trifft es natürlich auch alles, was darauf aufbaut. Was uns genau zum nächsten Thema bringt: die Cloud.

Lena Vogel: Also, Google Cloud hatte einen Ausfall, und der hatte eine sehr konkrete, sehr spürbare Folge: europäische Banken fielen aus. Namentlich genannt werden HSBC und Revolut, unter anderem.

Felix Hartmann: Das ist ein interessanter Fall, weil er zwei Debatten auf einmal bedient. Die erste ist die Abhängigkeitsdebatte. Hier sind große Finanzinstitute – also Unternehmen, bei denen Verfügbarkeit buchstäblich Geld kostet und regulatorisch relevant ist – die hängen an einem einzigen Cloud-Anbieter. Wenn Google ein Problem hat, haben sie ein Problem. Kein Fallback, keine Ausweichmöglichkeit, die Schalter sind zu.

Lena Vogel: Die zweite, und die ist fast interessanter, ist die Gegenprobe: Monzo. Die Bank hatte offenbar ein separates Cloud-Setup – also ein Setup, das nicht im selben Google-Cloud-Umfeld läuft – und genau dieses Ausfallsystem hat funktioniert. Monzo ist weitergelaufen, während die Konkurrenz down war.

Felix Hartmann: Und das ist der Beweis, den man in solchen Debatten selten bekommt. Normalerweise ist die Multi-Cloud-Diskussion ja rein rhetorisch: "Wir sollten Redundanz haben." Hier hat man ein reales Natur-Experiment. Ein Anbieter fällt aus, zwei Similar-Positioned-Banken, eine mit separatem Setup, eine ohne. Ergebnis: unmittelbar sichtbar.

Lena Vogel: Gleichzeitig haben die Kommentatoren die Preiskalkulation von Multi-Cloud nicht romantisiert. Ein separates Setup ist teuer. Es braucht Personal, das zwei Plattformen wirklich beherrscht. Es braucht Architekturentscheidungen, die Datensynchronisation zwischen den Umgebungen regeln. Monzo hat sich das offenbar geleistet – aber das ist eine Investitionsentscheidung, die nicht jede Firma treffen kann oder will.

Felix Hartmann: Es gibt da eine interessante Scheidebene in der Diskussion. Manche sagen: Multi-Cloud ist der richtige Weg für kritische Infrastruktur, Punkt. Andere sagen: Multi-Cloud ist ein Mythos, den Vertriebe erzählen, denn in der Praxis wird die Anwendung so auf eine Plattform zugeschnitten, dass sie nirgendwo anders läuft. Beides hat Argumente. Monzo zeigt, dass es geht – aber eben nicht gratis.

Lena Vogel: Was am Ende noch offen ist: die Ursache des Ausfalls selbst und was Google und die Kunden daraus ziehen. Ein Post-Mortem gibt es zum Zeitpunkt unserer Aufnahme nicht in belastbarem Detail. Und für Multi-Cloud-Strategien heißt das: Ein Einzelfall beweist, dass es funktioniert, aber nicht, dass sich jeder das leisten kann oder soll. Das ist der ungelöste Teil dieser Diskussion.

Felix Hartmann: Und von der Cloud weg geht's jetzt zu einem Thema, das auf den ersten Blick nichts mit Technik zu tun hat, aber sehr viel mit Vertrauen: dem Bereich zwischen Kriminalität, Extortion und Regulierung. Da gibt es zwei Geschichten, die sich thematisch ergänzen.

Lena Vogel: Die erste ist eine Ermittlungsgeschichte. Ermittlern zufolge hat ein Mann namens Edward Dubrovsky – der in der Branche als Ransomware-Verhandler bekannt war – mutmaßlich ShinyHunters geholfen. ShinyHunters ist natürlich eine der bekannteren Hackergruppen der letzten Jahre. Und Dubrovsky soll eine Extortionsseite namens "Shinywire" betrieben haben.

Felix Hartmann: Für die, die den Kontext brauchen: Ein Ransomware-Verhandler ist jemand, der als Vermittler zwischen Opfern und Angreifern auftritt, um Lösegeld zu verhandeln, oft im Auftrag der Versicherung oder des Managements. Es ist eine legitime, wenn auch fragwürdige Branche. Die Vorwürfe gegen Dubrovsky sind nun: Er stand mutmaßlich auf der falschen Seite dieser Mediation – er kannte die Opfer, ihre Finanzlage, ihre Druckpunkte. Das ist Insiderwissen, das im Extortion-Szenario Gold wert ist.

Lena Vogel: Und die zweite Komponente ist fast noch beunruhigender: ShinyHunters haben Daten erbeutet, die zum FBI gehören. Das ist bemerkenswert. Wenn selbst Strafverfolgungsbehörden Daten verlieren, dann hat das zwei Konsequenzen: erstens zeigt es, dass die Angreifer so weit reichen, dass selbst staatliche Stellen nicht immun sind. Zweitens hat das Auswirkungen auf laufende Ermittlungen – wenn die Angreifer FBI-Daten haben, wissen sie womöglich, wer gegen sie ermittelt.

Felix Hartmann: Die Kommentare dazu drehen sich stark um die Ironie der Situation. Die Branche, die eigentlich die Opfer schützen soll, wird selbst zum Angriffsvektor. Das wirft die Frage auf, wie diese Vermittler überhaupt überwacht werden: Wer prüft, dass ein Verhandler nicht auch für die andere Seite arbeitet? In einem Markt, wo Millionen Lösegeld fließen, ist die Versuchung offensichtlich.

Lena Vogel: Unklar ist natürlich der rechtliche Ausgang: Was passiert mit Dubrovsky, wo wird angeklagt, in welchem Staat? Das ist offen. Und parallel dazu gibt es die zweite Geschichte, die eine ganz andere Form von Durchsetzungsproblem zeigt: Ofcom und 4chan.

Felix Hartmann: Kontext: Ofcom ist die britische Regulierungsbehörde für Medien und Telekommunikation, und die Online Safety Act-Regulierung gilt auch für Plattformen, die aus UK-Sicht Nutzer in Großbritannien haben. 4chan hat sich geweigert, sich zu unterwerfen. Und jetzt hat Ofcom faktisch eine Niederlage eingeräumt.

Lena Vogel: Der Grund ist, salopp gesagt, Verfassungsrecht. US-Gerichte vollstrecken britische Zensurbeschlüsse kaum, weil die durch den First Amendment in Konflikt geraten. Das heißt, selbst wenn Ofcom Bußgelder verhängt oder Maßnahmen anordnet, die die US-Rechtsprechung als Meinungs- oder Redefreiheitsschutz sieht, gibt es praktisch keinen Weg, diese in den USA durchzusetzen.

Felix Hartmann: Die Kommentare dazu haben im Kern zwei Richtungen. Die erste: Das ist ein fundamental strukturelles Problem der Internet-Regulierung. Jede nationale Regulierungsbehörde, die transnationale Plattformen beaufsichtigen will, läuft früher oder später in die Jurisdiktionswand. UK kann Bußgelder verhängen, aber wenn die Plattform keine Präsenz im Land hat, kommt das Geld nie an. Das ist ein harter Befund für alle, die gehofft haben, Regulierung könne das Internet formen.

Lena Vogel: Die zweite Richtung in den Diskussionen ist die Gegenfrage: Ist das ein Fehler oder ein Feature? Manche finden, genau so soll es sein – ein einziges Land sollte nicht global bestimmen können, was im Netz erlaubt ist. Andere finden genau das furchtbar – denn es heißt auch, dass die wirksamste Regulierung die des Landes ist, in dem die Plattform sitzt, und diese Interessen nicht mit denjenigen anderer Nationen zusammenfallen.

Felix Hartmann: Man kann die Dubrovsky- und die Ofcom-Geschichte wirklich als Zwilling lesen: In beiden Fällen gibt es Regeln und Durchsetzungsbereitschaft, aber die tatsächliche Macht, sie anzuwenden, läuft ins Leere. Beim einen, weil der Akteur im Gray-Market operiert; beim anderen, weil eine andere Rechtsordnung die Regeln nicht anerkennt.

Lena Vogel: Und dieses "läuft ins Leere" – das beschreibt übrigens auch das nächste Thema ziemlich gut. Denn was, wenn nicht nur Regulierung, sondern das gesamte Wissens-Ökosystem unter Druck gerät, weil KI-Systeme Inhalte ungeprüft übernehmen? Da gibt es zwei Befunde von gestern, die zusammengehören.

Felix Hartmann: Der erste kommt aus der Wikipedia-Welt. Die Beobachtung ist: Wikipedia verliert Leser durch KI-Antworten. Das ist kein akademisches Randphänomen, sondern eine reale Besuchsentwicklung. Menschen, die früher auf Wikipedia gelandet wären, bekommen ihre Antworten jetzt direkt aus einem Chatbot oder einer KI-Suchfunktion – und klicken nie durch zur Quelle.

Lena Vogel: Die Autorin des Stücks bringt das auf eine Forderung: Forscher haben eine ethische Pflicht, offenes Wissen und Wikipedia zu verteidigen. Das ist bemerkenswert scharf formuliert. Der Punkt dahinter: Wikipedia entsteht aus Millionen ehrenamtlicher Stunden. Wenn die Besucherströme versiegen, versiegt auch langfristig der Nachwuchs an Beitragenden und vermutlich die Finanzierung. Die Modelle trainieren auf Wikipedia, ersetzen die Leserschaft, aber nicht das dahinterstehende System.

Felix Hartmann: In der Diskussion gab es dazu im Wesentlichen drei Lager. Erstens die, die sagen: Das ist ein Übergangsproblem, KI-Antworten mit Quellenverlinkung können Wikipedia sogar mehr Traffic bringen, wenn die Links ernst genommen werden. Zweitens die Skeptiker, die darauf hinweisen, dass die Klickrate über KI-Referenzen lächerlich klein ist gegenüber dem organischen Traffic von früher – die Verlinkung ist kosmetisch.

Felix Hartmann: Und drittens die strukturellen Kritiker, die sagen: Das eigentliche Problem ist nicht Traffic, sondern Autorenschaft. Wenn niemand mehr die Artikel liest, gibt es auch keine Korrektur-Leser, die Fehler finden.

Lena Vogel: Und dann kommt der zweite Befund, der die Skeptiker fast schwarz auf weiß bestätigt: das Peec-AI-Experiment. Die Kurzfassung: 50.000 erfundene Statistiken wurden online gestellt, und ChatGPT zitiert diese fiktiven Zahlen noch nach sieben Monaten. Sieben Monate! Die erfundenen Zahlen sind also ins Modell-Ökosystem eingedrungen und werden reproduziert, als wären sie echt.

Felix Hartmann: Der Kontrast dabei ist fast komisch: Google hat die Seite weitgehend deindiziert – also die klassische Suchmaschine hat reagiert und die Quelle aus dem Index entfernt, so gut das ging. ChatGPT hat die Inhalte aber offenbar absorbiert und gibt sie bis heute wieder. Das heißt, dascrawler-basierte System korrigiert sich, das Modellbasierte tut es nicht, oder deutlich langsamer.

Lena Vogel: Die Kommentare dazu machen auf einen Punkt aufmerksam, den viele übersehen: Bei einer Suchmaschine kannst du die Quelle entfernen, und die Information verschwindet relativ bald aus den Antworten. Bei einem Modell ist das Wissen in den Gewichten. Retraining ist teuer, selektives Vergessen ist Forschungsthema, nicht Standardfunktion. Das heißt: Fehlinformationen haben in LLMs eine viel längere Halbwertszeit als im klassischen Web.

Felix Hartmann: Die Verbindung zwischen den beiden Geschichten ist dann ziemlich direkt. Wikipedia leidet, weil die Antwort-Maschinen die Besucher abziehen. Und die Antwort-Maschinen sind zugleich anfällig dafür, erfundene Inhalte wie wenn sie Wahrheiten zu reproduzieren. Man entzieht also der kuratierten Quelle die Grundlage und ersetzt sie durch ein System, das nachweislich Müll anreichert, wenn die Quelle keinen Gegenwert mehr hat.

Lena Vogel: Was ungelöst bleibt: die Finanzierungsfrage. Wenn Wikipedia die Leserschaft verliert, wer zahlt dann langfristig die Rechenzentren, die Entwickler, die Community-Unterstützung? Spendenaufkommen ist an Sichtbarkeit gebunden. Das ist ein Problem, das man nicht mit einer Kampagne löst, sondern nur mit einer Umkehrung des Geschäftsmodells – und die hat noch niemand vorgeschlagen, der sie konkret beziffern kann.

Felix Hartmann: Aber wir haben auch gesehen, dass die KI-Welt nicht nur Probleme erzeugt. Es gibt nämlich einen ziemlich bemerkenswerten Trend von gestern, den man als "Open Source KI wird erwachsen" zusammenfassen kann. Da sind vier Geschichten, die zusammen ein Bild ergeben.

Lena Vogel: Fangen wir mit der vielleicht größten an: Google hat TorchTPU opensourcet. Das ist ein PyTorch-Backend für TPUs – Googles eigene Beschleuniger-Chips. Bis jetzt war TPU-Training praktisch gleichbedeutend mit "nutzt JAX oder XLA". PyTorch-Nutzer mussten Umwege gehen. Jetzt gibt es ein natives Backend mit ATen-Kernels, also den Grundbausteinen von PyTorch-Operationen, mit XLA-Cache und Distributed-Training-Unterstützung.

Felix Hartmann: Die Bedeutung davon ist größer, als es klingt. PyTorch ist der De-facto-Standard in der Forschung. Wenn jetzt PyTorch-Code nativ auf TPUs läuft, dann sinkt die Umzugshürde von GPU-Clustern auf TPU-Infrastruktur enorm. In den Kommentaren wurde das als Strategie-Debug gelesen: Google macht seine eigene Hardware für das Ökosystem der Konkurrenz-Community nutzbar, weil es mehr Compute-Nachfrage generiert, als man intern abdecken kann.

Lena Vogel: Und Google liefert Beispiele gleich mit – Llama und ResNet unter anderem – das heißt, es ist kein Code-Dump, sondern etwas, das man direkt ausprobieren kann. Das ist wichtig für die Adoption. Es zeigt auch: Der Trend geht dahin, dass Framework-Grenzen zunehmend irrelevant werden. Es gibt Compute, und es gibt Modelle, und die Werkzeuge darunter sind austauschbar.

Felix Hartmann: Die zweite Geschichte kommt von DeepSeek und ist fast noch aufschlussreicher für die Wirtschaftlichkeit. DeepInfer ist ein Open-Source-Inferenz-Framework, und die Zahlen sind bemerkenswert: 155 Billionen Tokens pro Tag werden verarbeitet, und der Umsatz beträgt ungefähr 38 Dollar pro Karte und Stunde.

Lena Vogel: 38 Dollar pro Karte pro Stunde ist eine Zahl, die man mal kurz einordnen muss. Eine moderne GPU-Instanz kostet in der Cloud deutlich mehr als das an Compute-Preisen. Wenn DeepSeek damit Income pro Karte schreibt, dann zeigt das, wie effizient ihre Inferenz-Pipeline optimiert ist – und es relativiert die sonst oft höhere Rechenpreis-Diskussion. Aber der Vorbehalt aus den Kommentaren: Aktuell unterstützt DeepInfer nur DeepSeek-V4.1-Flash.

Lena Vogel: Es ist also vor allem ein Framework, um die eigenen Modelle effizient zu servieren, kein generisches Werkzeug für beliebige Modelle.

Felix Hartmann: Was in der Diskussion strittig ist: Ist das ein Wettbewerbsvorteil, den man opensourcen sollte? Manche sagen, das ist Strategie – man gibt die Effizienz-Werkzeuge frei, um das Ökosystem an die eigenen Modelle zu binden. Andere finden genau das den Punkt: Open-Source-Infrastruktur democratize Compute-Zugang, auch wenn sie an spezifische Modelle gebunden ist.

Lena Vogel: Die dritte Geschichte ist Mistral Voxtral 3, und das ist der Bereich, in dem die Nutzer unmittelbar merken, was passiert: Speech-Modelle. Voxtral 3 umfasst Speech-to-Text und Text-to-Speech plus ein Voice-Agent-SDK. Das Besondere: über 50 Sprachen werden unterstützt, es gibt Diarisierung – also die Unterscheidung, wer in einem Gespräch wann spricht – und Emotionserkennung.

Felix Hartmann: Für europäische Nutzer ist der wichtigste Punkt vermutlich: EU-Hosting oder Self-Hosting. Das ist im Kontext von Datenschutz und Regulierung relevant, gerade in sensiblen Bereichen wie Kundenservice oder Gesundheitswesen, wo Voice-Daten oft nicht in US-Clouds sollen. Die Kommentatoren haben hervorgehoben, dass Self-Hosting bei Voice-Modellen deutlich seltener ist als bei Text-Modellen – hier hat Mistral eine Lücke adressiert.

Lena Vogel: Und die vierte Geschichte ist fast schon charmant: Jev Cards von TypeSafe. Das ist ein Quiz-Spiel, bei dem man gegen Jev antritt, das Vision-Modell von TypeSafe. Der Clou: Jev antwortet in etwa 0,3 Sekunden. Es ist Open Source, hat einen Mehrspieler-Modus und Leaderboards.

Felix Hartmann: Und das ist eigentlich ein sehr schönes Beispiel für den Trend, den wir gerade besprechen: KI wird zum Alltagsgegenstand. Nicht als produktives Tool, sondern als Spielgegner. Man testet sein eigenes Wissen gegen ein Modell und merkt dabei, was die Modelle können und was nicht. Das ist eine Form von AI-Literacy, die keine Vorlesung liefert. Es ist die Gamification des Verständnisses.

Lena Vogel: Der gemeinsame Nenner dieser vier Geschichten ist tatsächlich ganz prägnant: KI wird offener, günstiger und Alltagsgegenstand. TorchTPU öffnet die Hardware-Ebene, DeepInfer zeigt effiziente Inferenz als Open Source, Voxtral 3 macht Voice mit EU-Compliance zugänglich, und Jev Cards macht KI zum Spiel. Die Technologie demokratisiert sich gerade auf mehreren Ebenen gleichzeitig.

Felix Hartmann: Und wenn wir schon bei Werkzeugen sind, die demokratisiert werden – da gibt es einen ganz klaren Trend bei den Programmiersprachen, den man kaum übersehen kann: Rust ist dabei, die Entwickler-Werkzeuge zu übernehmen. Da gab es gestern zwei Geschichten.

Lena Vogel: Die erste ist die größere Splash-Story: Cloudflare hat "tsrs" vorgestellt, einen Rust-Port von TypeScript. Das ist bemerkenswert, weil es schon einen TS-Port in Go gibt, der von Microsoft selbst stammt. Und jetzt kommt Cloudflare mit einer Rust-Implementierung, die laut ihren Zahlen bis zu achtmal schneller ist und rund 70 Prozent weniger Speicher braucht als der Go-Port.

Felix Hartmann: Für Einsteiger in die Debatte: TypeScript ist die Sprache, in der vermutlich die meisten Web-Entwickler heutzutage arbeiten, und der TypeScript-Compiler ist ein zentrales Werkzeug. Wenn der doppelt so schnell läuft oder zehnfach, merkt man das bei jedem Typcheck, jedem Build, jedem Editor-Feedback. Die Zahlen von Cloudflare sind also nicht akademisch, sie sind direkt spürbar.

Lena Vogel: Und die Beteiligung des Oxc-Teams ist ein wichtiges Signal. Oxc ist selbst bekannt für sehr schnelle JavaScript-Tooling-Implementierungen in Rust. Dass die Leute, die schon Erfahrung mit diesem Paradigma haben, in Cloudflares Projekt einsteigen, zeigt: Da gibt es eine Community mit Pattern-Wissen, das hier angewandt wird. Das ist kein Ein-Mann-Projekt, sondern ein ausgereifter Ansatz.

Felix Hartmann: In den Diskussionen wurde natürlich sofort die Frage gestellt: Wie verhält sich das zum offiziellen Go-Port? Da gibt es einen echten Konflikt. Microsoft hat den Go-Port als offizielle Zukunft, Cloudflare macht parallel einen Rust-Port schneller. Die Kommentare schwanken zwischen "toll, Wettbewerb bringt Fortschritt" und "schade, dass die Energie nicht gebündelt wird". Eine klare Antwort, welcher Ansatz sich durchsetzt, gibt es nicht.

Lena Vogel: Die zweite Geschichte zeigt, dass es nicht nur um einzelne Tools geht, sondern um die Sprach-Infrastruktur selbst. Der Rust-Compiler 2026 bekommt einen neuen Trait-Solver, Polonius – das ist ein lang erwartetes Projekt für die Borrow-Checking-Analyse –, ein paralleler Frontend ist nahe der Stabilisierung, und es gibt schnellere Builds mit LLVM 23.

Felix Hartmann: Der Punkt mit den kleineren Target-Verzeichnissen ist dabei fast der konkret-steuerbare für den Alltag. Wer Rust entwickelt, kennt das Problem: Das Target-Directory explodiert im Speicherplatz, besonders bei großen Projekten mit vielen Dependencies. Das ist kein glamouröses Feature, aber es ist eines, das täglich auffällt.

Lena Vogel: Und der parallele Frontend ist der vielleicht wichtigste Punkt. Der Compiler ist heute der Flaschenhals bei großen Rust-Projekten – Build-Zeiten sind der häufigste Kritikpunkt an der Sprache überhaupt. Wenn das Frontend parallel läuft und die Build-Zeiten dadurch signifikant sinken, dann verschwindet ein ganzer Einwand gegen Rust.

Felix Hartmann: Man kann aus den beiden Geschichten wirklich den Trend ablesen: Rust etabliert sich nicht als Sprache, in der Anwendungen geschrieben werden, sondern als Sprache, in der Werkzeuge geschrieben werden. TypeScript-Compiler, JavaScript-Bundler, Python-Type-Checker, jetzt auch der Compiler selbst – die Infrastruktur der Software-Entwicklung wird gerade auf Rust umgebaut.

Lena Vogel: Und das ist eine Entwicklung, die man als Nutzer gar nicht direkt bemerkt, sondern nur als "alles ist schneller geworden". Was uns zu einer Ebene bringt, auf der man es sehr direkt bemerkt: den Alltag mit Geräten und Plattformen. Da gab es gestern drei Geschichten, die zusammen ein Muster ergeben.

Felix Hartmann: Die erste ist ein Klassiker der Kategorie "Software-Update bricht etwas Unerwartetes": iPadOS 27 bricht iPad-Präsentationen. Das Problem: Bei AirPlay zeigt das iPad bei einem App-Wechsel plötzlich den ganzen Bildschirm, statt nur der geteilten App.

Felix Hartmann: Wenn man also in einer Präsentation ist – etwa in einer Vorlesung – und wechselt zwischen Keynote und einer Notiz-App oder einem Umfrage-Tool, dann sehen die Zuschauer plötzlich alles: die Notizen des Dozierenden, die Umfrage-Ergebnisse, was auch immer gerade auf dem iPad passiert.

Lena Vogel: Das ist ein richtig ernstes Problem für Lehrsituationen. Denn die ganze Arbeitsweise "Ich zeige nur das eine Fenster, aber ich habe parallel Notizen offen" funktioniert nicht mehr, wenn jeder App-Wechsel den ganzen Bildschirm überträgt. Keynote und PowerPoint sind beide betroffen. Das heißt, das Problem liegt nicht bei den Präsentations-Apps, sondern im System bzw. in der AirPlay-Integration.

Felix Hartmann: Die Kommentare haben sich stark um die Ursache gestritten. Manche sehen es als AirPlay-Verhalten, das unter Umständen verändert wurde; andere vermuten eine grundlegende Änderung in der Fensterverwaltung von iPadOS 27. Was klar ist: Der Workflow, der seit Jahren funktioniert hat, ist gebrochen, und die Betroffenen sind genau die, die auf Zuverlässigkeit angewiesen sind – Dozierende, Trainer, Präsentierende in Meetings.

Lena Vogel: Und es illustriert wieder dasselbe Muster, das wir heute schon mehrfach gesehen haben: Ein System-Update verändert Verhalten, das von anderen darauf aufsetzt. PHP 5 bis 8, iOS-Präsentationen, Cloud-Abhängigkeit – die Grundschicht ändert sich, und die Anwendungen darüber brechen.

Felix Hartmann: Die zweite Geschichte in diesem Themenblock ist die Abogeschichte von Facebook. Und die ist bemerkenswert direkt: Facebook verlangt ab 14,99 Dollar pro Monat für mehr als zwei Links pro Monat auf Pages. Zwei Links pro Monat – gratis. Alles darüber kostet Geld. Und mit 49,99 Dollar bekommt man acht Links. Und das Wichtigste: Kommentare zählen auch dazu.

Lena Vogel: Das ist eine Verschärfung gegenüber dem, was man sonst kennt. Normalerweise denkt man bei Pages-Limits an Posts. Hier ist die Einschränkung "Links", und ausdrücklich mit Kommentaren eingeschlossen. Das heißt, wenn du in den Kommentaren deiner eigenen Page einen Link teilen willst, zählt das gegen dein Gratis-Kontingent.

Felix Hartmann: Die Kommentare dazu haben im Wesentlichen zwei Lesarten. Die erste: Das ist der logische Endpunkt der Reichweiten-Krise von Pages. Organische Reichweite ist seit Jahren gefallen, jetzt wird die letzte verbliebene Funktion – also Link-Sharing – direkt bezahlbar gemacht. Man vermarktet nicht mehr Reichweite, sondern die简单的 Möglichkeit, überhaupt zu verlinken.

Lena Vogel: Die zweite Lesart ist die kritische: Das ist ein Testballon. Wenn Pages-Betreiber das zahlen, dann ist das ein Modell, das auch auf andere Plattformen ausgeweitet werden könnte. Wenn sie nicht zahlen und die Pages verlassen, dann hat Facebook verlorene Content-Ersteller, aber auch ein Saubermachen der Plattform. Beide Ausgänge haben Konsequenzen.

Felix Hartmann: Was auf dem Spiel steht: Pages sind oft die digitale Präsenz von kleinen Unternehmen, Vereinen, Communities. Wenn Link-Sharing dort hinter einer Paywall landet, ist die Frage, ob diese Organisationen überhaupt noch auf Facebook erreichbar sind – oder ob sie auf eigene Websites umsteigen müssen. Das ist ein echtes Verschiebepotenzial.

Lena Vogel: Und hier kommt die Gegenbewegung, die dritte Geschichte: microG GmsCore. Das ist eine freie, Apache-2.0-lizenzierte Neuimplementierung von Google Play Services. Für die, die den Kontext brauchen: Google Play Services ist ein proprietäres Paket, das auf fast jedem Android-Gerät läuft und Funktionen wie Push-Benachrichtigungen, Standortdienste und viele API-Aufrufe bereitstellt.

Lena Vogel: Wenn man ein freies Android will – etwa LineageOS oder andere AOSP-ROMs – dann fehlen diese Funktionen, weil sie proprietär sind.

Felix Hartmann: MicroG reimplementiert genau das, open source, mit der Apache-2.0-Lizenz. Der Haken: Damit die Apps funktionieren, braucht man Signature Spoofing. Das heißt, das System muss so manipuliert werden, dass microG sich als die offiziellen Google Play Services ausgeben kann – denn Apps prüfen normalerweise die Signatur dessen, was sie ansprechen.

Lena Vogel: In den Diskussionen wurde deutlich, dass das ein Dauerprojekt ist: microG existiert seit vielen Jahren und hat eine treue Community. Der Aufwand ist aber real – Signature Spoofing ist nicht in jedem ROM standardmäßig aktiviert, weil es aus Sicherheitssicht ein Kompromiss ist. Wer microG nutzt, akzeptiert bewusst eine Schwäche in der Sandbox-Trennung, um Google-Dienste zu ersetzen.

Felix Hartmann: Der thematische Bogen über diese drei Geschichten ist wirklich: Wer bestimmt über Bildschirme, Links und freie Software? Apple ändert das Verhalten deiner Präsentation per System-Update. Facebook bestimmt, ob deine Inhalte überhaupt verbreitet werden können. Und microG ist der Versuch, sich aus dieser Abhängigkeit zu lösen – mit dem Preis von technischem Mehraufwand und Sicherheits-Kompromissen.

Lena Vogel: Man kann es auch so sagen: Auf der einen Seite die großen Plattformen, die den Alltag der Nutzer immer weiter einhegen. Auf der anderen Seite die Open-Source-Bewegung, die sich dagegen wehrt, aber eben mit deutlich weniger Ressourcen. Der Ausgang dieser Auseinandersetzung ist offen.

Felix Hartmann: Und von diesem eher ernsten Thema können wir jetzt zu einem wechseln, das deutlich leichteres Terrain hat – aber das nonetheless dasselbe Prinzip illustriert: Software, die komplexe Zusammenhänge spielerisch verständlich macht. Da gibt es zwei Projekte, die beide auf ihre Art versuchen, reale Prozesse in interaktiver Form erfahrbar zu machen.

Lena Vogel: Das erste ist ein Fanprojekt rund um IKEA. Jemand hat interaktive 3D-Nachbauten echter IKEA-Anleitungen im Browser gebaut – konkret BILLY, das Regal, und LACK, der Beistelltisch. Die Mechanik ist: Du kannst die Möbel in 3D zusammensetzen, und die Teile, die Reihenfolge und die Hardware-Zahlen folgen exakt dem Original-Handbuch.

Felix Hartmann: Das Detail mit den Hardware-Zahlen ist übrigens das, was das Projekt über eine reine Spielerei hinaushebt. Es ist nicht "hier ist ein Regal, bau es irgendwie zusammen", sondern "hier sind die 14 Schrauben, hier ist die exakte Reihenfolge, so wie IKEA es im Handbuch beschreibt". Das ist eine Abbildungstreue, die zeigt, dass der Autor die Originale wirklich studiert hat.

Lena Vogel: Wichtig für die Nüchternheit: Es ist nicht von IKEA. Das ist ein unabhängiges Projekt, und IKEA hat damit nichts zu tun. Die Kommentare haben das als nettes Beispiel für "Fancherz"-Projekte gesehen, die ohne große Ambition etwas helfen können – etwa Menschen, die visuell lernen statt über abstrakte Flach-Zeichnungen.

Felix Hartmann: Das zweite Projekt ist noch ambitionierter im Anspruch: "Permit Pending". Das ist eine Stadtbau-Simulation im Browser, bei der jeder Bau die volle bürokratische Prozedur durchlaufen muss: Genehmigungen, Anhörungen – Hearings –, Klagen und Wahlzyklen.

Lena Vogel: Das ist natürlich eine Satire auf die reale Stadtplanung. Der Punkt ist: In normalen Stadtbau-Spielen wie SimCity baust du ein Gebäude und es steht. In Permit Pending ist das Bauen selbst der Prozess. Du musst mit Anwohnern verhandeln, Klagen abwehren, Wahlzyklen überstehen. Das Spiel macht die Bürokratie zum Gameplay, statt sie als Reibung wegzuabstrahieren.

Felix Hartmann: Und das ist eine interessante Design-Entscheidung. Die Kommentare dazu haben zwei Richtungen. Manche finden es herrlich: Endlich ein Spiel, das die Realität der Stadtentwicklung abbildet, in der ein Projekt oft jahrelang im Genehmigungsprozess steckt. Andere finden es frustrierend – was, zugegebenermaßen, der Punkt sein könnte. Frustration als pädagogisches Mittel.

Lena Vogel: Was die beiden Projekte gemeinsam haben: Sie nutzen die Kraft der Interaktion, um Prozesse verständlich zu machen, die sonst nur abstrakt oder als Text erlebt werden. Eine IKEA-Anleitung ist eine Flach-Zeichnung – in 3D wird sie physisch nachvollziehbar. Eine Bau-Genehmigung ist Papierkram – als Spiel wird sie zum erlebbaren Hindernisparcours.

Felix Hartmann: Und das führt sehr gut zum letzten Themenblock, der uns zurückbringt zu den Menschen hinter diesen Systemen. Vier Geschichten, die um Verantwortung, Erinnerung und langfristige Folgen kreisen.

Lena Vogel: Die erste ist eine späte Bilanz: 16 Jahre nach Deepwater Horizon zeigen aktuelle Studien, dass die versprochenen Schutzmaßnahmen offenbar keinen Schutz gebracht haben. Die Regeneration ist kaum messbar, BP-Zahlen belegen das. Das war die Öl-Katastrophe im Golf von Mexiko 2010, die größte marine Ölkatastrophe der Geschichte.

Felix Hartmann: Was die Kommentare an dieser Bilanz besonders betont haben: Es geht nicht nur um die ökologische Schadensbilanz, sondern auch um die finanzielle. BP hat rund 140 Milliarden Dollar gezahlt und musste sogar die Dividende aussetzen – das war ein historischer Moment, denn die Dividende war bis dahin als unantastbar galt. Und trotzdem: 140 Milliarden Dollar und ein ausgesetzter Dividenden-Zahlstop haben die Umwelt offenbar nicht regeneriert.

Lena Vogel: Der Punkt, der daraus gezogen wurde, ist unbequem: Es gibt offenbar eine Schadensgröße, bei der finanzielle Kompensation zwar die股东 beruhigen und das Unternehmen am Leben halten kann, aber die tatsächliche Regeneration nicht erzwingen kann. Man kann 140 Milliarden zahlen und trotzdem keine intakte Küsten-Ökologie zurückbekommen. Das ist eine Warnung für jede Debatte über "Zahlung statt Vermeidung".

Felix Hartmann: Und dieses Thema der langfristigen Folgen – da passt eine medizinische Geschichte, die auf den ersten Blick weit weg ist von Öl-Plattformen, aber eigentlich exakt dasselbe Muster zeigt: Benzodiazepin-Entzug. Die Kernaussage: Benzodiazepin-Entzug kann monatelang dauern und intensiver sein als Opiat-Entzug.

Lena Vogel: Für Kontext: Benzodiazepine sind Angstlöser und Schlafmittel – Medikamente wie Diazepam, Lorazepam, Alprazolam. Sie wirken auf das zentrale Nervensystem, und die Gewöhnung ist bekannt. Was die Quelle nun betont: Der Entzug ist nicht nur unangenehm, sondern kann monatelange, teils schwere Symptome verursachen – und das intensiver als bei Opiaten, wo die Entzugsphase zwar heftig ist, aber relativ kurz.

Felix Hartmann: Die Warnung, die daraus gezogen wird, betrifft die Langzeit- oder Dauerverschreibung. Benzodiazepine sind für Kurzzeitanwendung gedacht, aber in der Praxis werden sie oft über Jahre verschrieben. Bei diesen Patienten ist der Entzug dann ein vielfach schwereres Problem, als wenn man die Medikamente nur für Wochen genommen hätte. Die Botschaft ist klar: Vorsicht bei Dauerverschreibung, das Entzugsrisiko wird systematisch unterschätzt.

Lena Vogel: Der gemeinsame Punkt mit Deepwater Horizon ist fast schon philosophisch: Es gibt Handlungen, deren Folgen man nicht durch nachträgliche Zahlungen oder Entzugsprogramme rückgängig machen kann. Manche Schäden sind strukturell. Und in beiden Fällen – Pharma wie Öl – war die Versuchung groß, das Problem durch Geld zu lösen statt durch Vermeidung.

Felix Hartmann: Und von der Verantwortung für Schäden zur Verantwortung für die Zukunft: Steve Krouse hat eine Frage gestellt, die viele in seiner Situation kennen: Was soll ich meinem Sohn beibringen? Und um die Frage zu beantworten, greift er auf Neil Postmans Buch "The End of Education" zurück.

Lena Vogel: Postman war ein Medien- und Kulturkritiker, und sein Buch argumentiert im Kern, dass Bildung nicht nur Wissensvermittlung ist, sondern immer auch ein narratives Projekt – die Frage, welche Geschichte eine Gesellschaft sich über sich selbst erzählt und welche Ziele daraus folgen. Krouse überträgt das auf das KI-Zeitalter: Wenn Modelle alles Wissen abrufen können, was ist dann noch der Sinn von klassischem Lernen?

Felix Hartmann: Das ist eine Frage, die in den Diskussionen viel Resonanz gefunden hat, weil sie existenziell ist für Eltern und Pädagogen. Die klassischen Bildungsziele – Faktenwissen, Abstraktionsfähigkeit, Disziplin – sind teilweise automatisierbar. Was bleibt? Manche Kommentare sagen: Kritisches Denken und Urteilsvermögen, also die Fähigkeit zu erkennen, wann ein Modell Unsinn erzählt. Andere sagen: Kreativität und Originalität. Wieder andere sagen: Charakter und Beziehungen.

Lena Vogel: Und das ist der Punkt, an dem Postman relevant wird: Er würde sagen, es geht nicht um die Fähigkeiten, sondern um die Ziele. Man muss zuerst klären, wozu Bildung da ist, bevor man entscheidet, was sie vermitteln soll. Die Diskussion dreht sich oft zu sehr um die Skills und zu wenig um den Zweck.

Felix Hartmann: Und das bringt uns zum letzten Punkt, der emotionalste Geschichte des Tages: Bob Cringely ist gestorben, am 3. Oktober 2026. Der Autor des Nachrufs erinnert sich an eine 30-jährige Zusammenarbeit.

Lena Vogel: Für die, die den Namen nicht kennen: Bob Cringely war eine sehr bekannte Figur in der Tech-Journalistik. Er schrieb Kolumnen, machte Fernsehen, war ein scharfer Beobachter der Industrie. Das Projekt "Pronto" wird im Nachruf erwähnt, ebenso seine Journal- und TV-Karriere und verschiedene Startup-Ideen, die die beiden zusammen entwickelt haben.

Felix Hartmann: Der Nachruf ist bemerkenswert, weil er nicht nur trauert, sondern auch die Arbeitsweise dieser Zusammenarbeit würdigt: 30 Jahre an Ideen arbeiten, Projekte anstoßen, Fernsehsendungen machen – eine Partnerschaft, die über Jahrzehnte hielt, in einer Branche, die für ihre kurzen Aufmerksamkeitszyklen bekannt ist.

Lena Vogel: Und es ist ein passender Abschluss für unsere heutige Episode, weil es uns zurückführt zu dem, was wir die ganze Zeit besprochen haben. Hinter jeder Infrastruktur, jedem Framework, jedem Cloud-Anbieter, jedem Regulierungsstreit stehen Menschen, die Dinge gebaut haben, die Ideen verteidigt haben, die sometimes über Jahrzehnte an einer Sache dran geblieben sind.

Felix Hartmann: Cringelys Tod ist eine Erinnerung daran, dass die Tech-Industrie eine Erinnerungskultur braucht. Sie vergisst ihre Pioniere schnell, weil sie immer auf das nächste Release schaut. Aber ohne die Leute, die in den 80ern und 90ern die Grundlagen gelegt haben, gäbe es kein PHP, kein Tor, keine Cloud, kein PyTorch.

Lena Vogel: Und das ist vielleicht die Verbindung aller heutigen Geschichten: Die Systeme, auf denen wir aufbauen, sind von Menschen gemacht, verwundbar, oft fragil – aber auch reparierbar, verbessert, weitergegeben. Von PHP-Warnungen über Tor-Exit-Nodes bis zu Nachrufen – es geht immer um die Frage, wie wir mit dem umgehen, was andere vor uns gebaut haben.

Felix Hartmann: Das war's von uns für heute. Danke, dass du dabei warst. Wir melden uns wieder, wenn die nächste Runde Geschichten da ist.

Lena Vogel: Bis dann – und sicher deine PHP-Server!