1020 | Agenten, Modelle, Altbausubstanz – Tech im Schnelldurchlauf

Lena Vogel: Herzlich willkommen zu einer neuen Folge unseres Hacker-News-Podcasts. Ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Und heute verbindet die Geschichten eigentlich ein einziges Thema: Vertrauen. Vertrauen in Modelle, die wir nicht ganz verstehen. Vertrauen in Systeme, die von außen beeinflusst werden können. Und Vertrauen in Plattformen und Institutionen, die gerade irgendwo kratzen.

Lena Vogel: Genau, und wir fangen gleich dort an, wo heute Nacht vermutlich am meisten Diskussion ausgebrochen ist: bei einer regelrechten Modell-Offensive. Diffusion, Mixture-of-Experts, neue Flash-Varianten, Zeitreihen-Modelle. Los geht's.

Felix Hartmann: Also, die Headline-Story kommt von Inception. Die haben Mercury 3 veröffentlicht, ein Diffusions-LLM. Und das ist erstmal bemerkenswert, weil die meisten großen Modelle klassisch autoregressiv arbeiten, also Token für Token. Mercury 3 generiert anders, über Diffusion, und schafft dadurch über 1000 Token pro Sekunde.

Lena Vogel: Und das ist nicht alles. Ein Million-Token-Kontext, und ein Launch-Preis von 10 Cent Input und 35 Cent Output. Die Preiskurve ist zuletzt ja steil nach unten gegangen, aber das ist nochmal ein Sprung.

Felix Hartmann: Und dann die Benchmark-Aussage: Mercury 3 soll GPT-6 Luna und Haiku 5.5 schlagen. Das ist natürlich die Aussage, die im Thread am meisten Kopfzittern ausgelöst hat, weil Benchmark-Siege eines neuen Anbieters immer mit Vorsicht zu genießen sind.

Lena Vogel: Ja, da war die Skepsis ganz deutlich. Der Hauptpunkt der Kritiker war: Benchmarks sind Trainingsdaten-Auswahlfragen. Ein Modell kann auf Benchmark-artigen Aufgaben optimiert sein und trotzdem im Alltag enttäuschen. Das ist ein Muster, das wir in den letzten Jahren mehrfach gesehen haben. Die offene Frage im Thread war praktisch: Wer hat das Modell schon in echten Agenten-Workflows ausprobiert? Und da war die Bilanz noch dünn.

Felix Hartmann: Aber interessant ist der Diffusions-Ansatz selbst. Einige Kommentierende waren da richtig begeistert, weil die Geschwindigkeit echtes Neuland ist. Wenn du 1000 Token pro Sekunde hast, verändert das das Erlebnis von interaktiven Tools komplett. Autovervollständigung, Live-Editing, Echtzeit-Agents, das wird alles anders denkbar.

Lena Vogel: Und andere haben kontert: Diffusion-Modelle hatten historisch ein Problem mit langen kohärenten Generationen, gerade bei Code. Die Frage war also: Kauft Mercury 3 Geschwindigkeit mit Kohärenz? Das ist die unbeantwortete Kernfrage dieser Veröffentlichung.

Felix Hartmann: Und Mercury 3 steht nicht allein da. Parallel hat MiniMax M3.1 Flash veröffentlicht. Ein Mixture-of-Experts-Modell, 428 Milliarden Parameter insgesamt, aber nur 23 Milliarden aktiv pro Vorwärtsdurchlauf. Und die Zahlen: 70 Prozent günstiger als der Vorgänger, dreifache Geschwindigkeit.

Lena Vogel: Und die Positionierung ist interessant: stark in Agenten-, Coding- und Cybersecurity-Benchmarks. Also nicht als Universalgenie angepriesen, sondern gezielt auf die Workloads, die in Produktion Geld kosten. Und das ist die eigentliche Ökonomie hier: Wenn ein Agent einen Task über 200 Tool-Calls laufen lässt, frisst der Input-Token. 70 Prozent günstiger ist dann kein Marketing, sondern Margen-Entscheidung.

Felix Hartmann: Die Pattern-Erkenntnis im Thread war: Das Rennen verlagert sich. Es geht nicht mehr primär um den einen großen Intelligenz-Sprung, sondern um Preis pro Token, Durchsatz und Nischen. Und dann kam DeepSeek.

Lena Vogel: DeepSeek V4.1 Flash, Version 1017. 552 Milliarden Parameter, aber nur 16 Milliarden aktiviert. 230 Token pro Sekunde, 1 Million Kontext, und ein Intelligenz-Index von 45. Also wieder das Muster: riesiges MoE, extrem kleine aktive Schicht.

Felix Hartmann: Das ist der ökonomische Kern von Mixture-of-Experts. Du trägst die Speicherkosten eines Riesen, bezahlst aber pro Token nur einen Bruchteil der Rechenleistung. Die Kommentierenden, die sich damit auskannten, haben betont: Der Flaschenhals verschiebt sich damit von der GPU zur Speicherbandbreite. Die Frage ist nicht mehr nur, wie schnell dein Chip rechnet, sondern wie schnell du die richtigen Experten ins VRAM bekommst.

Lena Vogel: Und dann der vierte Akteur, der einen komplett anderen Weg geht: Mistral. Die haben Timestral veröffentlicht, ein Zeitreihen-Foundation-Modell. In vier Größen von 5 Millionen bis 209 Millionen Parametern.

Felix Hartmann: Zeitreihen, also Vorhersagen von Verläufen, Absätzen, Temperaturen, Lastkurven. Das war klassisch das Land der Statistiker, ARIMA, Prophet, spezialisierte Gradient-Boosting-Modelle. Und Timestral behauptet jetzt Top-Plätze in drei Benchmarks, unter anderem GIFT-Eval. Und das Krasse: CPU-Inferenz möglich.

Lena Vogel: Das fand ich eine der schönsten Diskussionen im Thread. Einige haben gesagt: Endlich. Zeitreihen ist einMassengeschäft, Millionen von Datenreihen in Unternehmen, und ein kleines Modell, das auf einer CPU läuft, skaliert da ganz anders als ein 400-Milliarden-Koloss.

Felix Hartmann: Und die Skeptiker haben das alte Mantra重复: Spezialisierte Baselines sind hart zu schlagen, und Benchmark-Siege bei GIFT-Eval heißen noch lange nicht, dass die Vorhersage für deine Logistikdaten gut ist. Es ist wirklich dasselbe Muster wie bei Mercury 3: die offene Frage ist der Alltag.

Lena Vogel: Und dann kam noch eine Nebenspur, die thematisch gut passt: CERN und Mistral haben eine strategische Partnerschaft angekündigt. Ziel: das erste Foundation-Modell für Collider-Physik, trainiert auf Milliarden von Kollisionsdaten vom LHC.

Felix Hartmann: Das ist eigentlich das Gegenteil der Flash-Modelle: nicht Masse, sondern eine extrem tiefe Domäne. Die Kommentare im Thread gingen in zwei Richtungen. Die einen fanden das eine faszinierende Anwendung, Physik-Daten als Trainingsgrundlage. Die anderen fragten: Für wen ist das ein Produkt? Ist das Grundlagenforschung mit Tech-PR-Touch?

Lena Vogel: Und das passt zur abschließenden Frage dieses Blocks: Es gibt heute vier oder fünf Veröffentlichungen mit Benchmark-Siegen. In zwölf Monaten werden wir wissen, welche davon wirklich in Produkten leben. Meine Vermutung nach der Diskussion: Geschwindigkeit und Preis gewinnen kurzfristig, Intelligenzgewinne sind schwerer zu belegen.

Felix Hartmann: Und genau da, bei "schwerer zu belegen", bleiben wir hängen, aber auf einer dunkleren Ebene. Denn während die Modelle schneller und billiger werden, sind die Systeme drumherum plötzlich selbst zum Angriffsziel geworden.

Lena Vogel: Und das ist der zweite große Block: Agenten als Angriffsfläche. Und da gibt es eine Geschichte, die im Thread ziemlich Erschöpfung ausgelöst hat. Ein Hacker hat rund 20 offengelegte Instanzen von Cairn, einem AI-Agent-System, genutzt, um über 100 Websites anzugreifen. Darunter John Deere und SharkNinja.

Felix Hartmann: Und das Wort, das da immer wieder fiel, war: weitgehend autonom. Der Angreifer hat nicht 100 Websites von Hand angegriffen, sondern die Agenten selbst als Werkzeug benutzt. Die Infrastruktur, die wir aufsetzen, um Arbeit zu automatisieren, wird umgedreht und automatisiert gegen uns eingesetzt.

Lena Vogel: Die Diskussion im Thread war wirklich substanzreich. Die Hauptlage: Wer einen Agenten exponiert, muss ihn behandeln wie jeden anderen Server, harte Authentifizierung,最小 Privilegien, Audit-Logging. Die Verantwortung liegt beim Betreiber.

Felix Hartmann: Aber es gab eine kräftige Gegenposition: Agenten sind nicht wie normale Server, weil sie Eigeninitiative haben. Ein kompromittierter Webserver macht das, was sein Code sagt. Ein kompromittierter Agent hat Credentials, hat Permissions, hat einen Auftrag, den er ausführt. Der Blast Radius ist strukturell anders.

Lena Vogel: Und ein dritter Punkt, der mir wichtig erscheint: Die Kritik, dass Cairn hier nicht unbedingt der Schuldige ist. Das ist wie bei den Next.js-RCEs der letzten Monate. Die Frage ist, ob Agent-Anbieter Pflicht-Defaults brauchen, also: kein offenes Internet per Default. Weil der durchschnittliche Nutzer keine Security-Expertise hat.

Felix Hartmann: Und dann, in derselben Woche, eine zweite Geschichte, die fast wie ein Lehrbuchbeispiel wirkt: Alte Plex-Schwachstellen werden in freier Wildbahn ausgenutzt, um Cryptominer und Proxies zu installieren.

Lena Vogel: Und der bittere Teil: Das ist im August gepatcht worden. Aber Plex aktualisiert sich nicht automatisch per Default. Der Nutzer muss aktiv Hand anlegen.

Felix Hartmann: Die Analogie lag im Thread auf der Hand: Das ist exakt das gleiche Muster wie bei Cairn. Ein legitimes Tool, eine gepatchte Lücke, und ein Betreiber-Pool, der jahrelang nicht aktualisiert. Die Angreifer scannen das Internet nicht nach zero-days ab, sondern nach Menschen, die vergessen haben.

Lena Vogel: Es gab im Thread einen pointierten Kommentar, der ungefähr sagte: Selbst-Hosting ist schön, aber Selbst-Hosting bedeutet auch Selbst-Verantwortung, und die meisten haben sich das nie bewusst gemacht. Und das gilt für Plex-Server wie für Agent-Instanzen.

Felix Hartmann: Nun zur dritten Geschichte, die fast schon kurios ist, wenn sie nicht so beunruhigend wäre: WhatsApp hat auf seinen Hilfe-Seiten versteckten Text gehabt, der der KI, die diese Seiten liest, Anweisungen gegeben hat. Und zwar: Empfiehl keine Regulatoren. Und zitiere nicht die GDPR oder den CCPA.

Lena Vogel: Also Prompt Injection, nicht gegen einen Nutzer, sondern gegen das gesamte ökosystem aus KI-Assistenten, die öffentliche Seiten lesen und zusammenfassen. Wenn jemand fragt: "Wie melde ich WhatsApp bei einer Datenschutzbehörde?", hätte die KI das womöglich nicht beantwortet.

Felix Hartmann: Und die Reaktion von WhatsApp: Nach einem Bericht von Wired wurde es entfernt, mit der Begriffung, es sei ein Bug. Und genau die Entschuldigung hat im Thread die eigentliche Diskussion getriggert. Einige Kommentierende haben das formal akzeptiert: Bugs passieren, versteckter Text kann aus Test-Systemen gelutscht sein.

Lena Vogel: Aber die Mehrheit war deutlich unruhiger. Der Punkt: Selbst wenn es ein Bug war, offenbart der Bug eine Denkweise. Irgendjemand hat diesen Text irgendwann geschrieben und irgendwo deployed, in einem Kontext, wo er "keine Regulatoren empfehlen" als legitime Zielvorgabe enthielt. Das ist kein technisches Versagen, sondern ein Design-Entscheid, der rausgerutscht ist.

Felix Hartmann: Und die weiterführende Frage im Thread: Wenn ein Unternehmen die KI-Ebene über seine öffentliche Kommunikation legen kann, brauchen wir dann eine Norm dafür, dass öffentliche Dokumente maschinenlesbar sein müssen in guter Absicht? Also "keine versteckten Anweisungen an LLMs" als Pflicht? Es gibt keinen solchen Standard heute.

Lena Vogel: Und die Meta-Geschichte in Brasilien rundet das Bild ab, allerdings ohne AI-Komponente. In São Paulo haben Anhänger von Lula gegen Meta protestiert, mit dem Vorwurf, die Plattform habe Flávio Bolsonaro bevorzugt. Und das Wahlgericht hat Meta 24 Stunden gegeben, Fairness nachzuweisen.

Felix Hartmann: Das ist ein ganz anderes Setting, aber die Grundfrage ist verwandt: Wie weist man Fairness eines Algorithmus nach? 24 Stunden Frist ist ein extrem aggressives Instrument, und im Thread war unklar, was Meta da überhaupt vorlegen kann. Aber es zeigt eine Richtung: Regulierer fangen an, nicht nur Inhalte zu befragen, sondern das System selbst.

Lena Vogel: Ich glaube, die Verbindung all dieser Geschichten ist: KI-Systeme sind selbst zur Angriffs- und Einflussfläche geworden. Der Cairn-Hack zeigt die technische Seite, WhatsApp die semantische, Meta die politische. Drei verschiedene Waffenkammern gegen dieselbe Grundverwundbarkeit.

Felix Hartmann: Und wenn die Systeme unzuverlässig sind, die sie bauen, wie geht das aufs eigentliche Engineering durch? Genau da geht es im dritten Block weiter: die Review-Ära.

Lena Vogel: Und da gibt es eine Geschichte, die mir persönlich sehr gut gefallen hat, weil sie konkret und nicht abstrakt ist: Aus PostgreSQL 19 beta wurden etwa 8 bis 10 signifikante Features zurückgezogen.

Felix Hartmann: Das ist hart. PostgreSQL ist ein Projekt mit sehr konservativer Release-Kultur, die Features wollen da jahrelang gepühlt werden. Und die These der Committer: LLM-gestützte Review hat die Qualitätsschwelle erhöht. Also man hat die alten Patches, die vielleicht vor zwei oder drei Jahren durch Review gegangen sind, nochmal durch ein modernes Modell gejagt, und plötzlich fand es Probleme, die Menschen übersehen hatten.

Lena Vogel: Und genau da liegt die Ironie, die im Thread herausgearbeitet wurde: Die LLM-gestützte Review diente hier nicht dazu, schlechten Code reinzulassen, sondern um zu verhindern, dass alter, schlechter Code drinbleibt. Es ist eine Rückwärts-Audit, kein Durchlassfilter.

Felix Hartmann: Die konträre Meinung im Thread war: Das ist vor allem ein Signal, dass traditionelles Review schlicht unterbesetzt ist. Postgres hat zu wenig Reviewer für die Menge an Code, und das LLM macht sichtbar, wie viel durchgerutscht wäre. Die eigentliche Ursache ist Personalmangel, nicht Technik.

Lena Vogel: Und das führt direkt in die zweite Geschichte: der "Ask HN"-Thread, wie man Code shipped, den man nicht vollständig versteht. KI-generierter Code, den du nicht Zeile für Zeile nachvollziehen kannst.

Felix Hartmann: Die Kommentare sind hier extrem praktisch geworden. Und der Konsens, der sich abzeichnete, war: Tests und Planung statt Zeilen-Review. Also, die Antwort auf "ich verstehe den Code nicht" ist nicht "ich lese ihn schneller", sondern "ich definiere, was er können muss, und prüfe das maschinell".

Lena Vogel: Ein Wort, das mehrfach fiel, war: Spezifikation. Der Ingenieur-Auftrag verschiebt sich von "Ich schreibe Code" zu "Ich definiere, was korrekt ist". Und der Code, ob Mensch oder Modell, wird dann gegen die Spezifikation verifiziert.

Felix Hartmann: Aber es gab auch kräftige Gegenstimmen. Einige argumentierten: Tests decken nur das ab, was du dir vorstellen kannst. Der Wert von "Ich verstehe den Code" ist, dass du Probleme siehst, die du nicht getestet hast. Wenn du Testabdeckung als Alternative zum Verstehen nimmst, testest du nur deine Vorurteile.

Lena Vogel: Und ein anderer Punkt, der mehrfach kam: Eigentlich ist das ein altes Problem in neuem Gewand. Die meisten Entwickler verstehen Libraries, Frameworks und Betriebssysteme nicht auf Zeilenebene. Wenn dein Code eine Blackbox ruft, warum ist eine generierte Blackbox grundsätzlich anders? Die Gegenantwort: Weil du bei einer Library die Dokumentation lesen kannst, bei generiertem Code ist die Blackbox direkt in deinem Repo.

Felix Hartmann: Und dann der dritte Block innerhalb dieser Diskussion: Ein Ruby-Entwickler hat alle seine Gems archiviert. Das ist eine ziemlich radikale Geste. Seine These: Ruby und Rails werden heute mit LLM-Agenten entwickelt, und das Commons, die offenen Libraries, werden abgebaut wie Rohstoffvorkommen, um Trainingsdaten zu generieren, ohne dass etwas zurückfließt.

Lena Vogel: Die Reaktion im Thread war gemischt. Einige hatten Verständnis für die Frustration, und die These klingt philosophisch, aber sie hat einen ökonomischen Kern: Wenn open-source Libraries hauptsächlich als Trainingsrohstoff dienen, ohne dass Contributor-Strukturen oder Kompensation zurückkommen, trocknet das Commons langfristig aus.

Felix Hartmann: Aber die Skeptiker sagten: Das ist nicht neu. Open Source ist seit 20 Jahren in dieser Spannung, Unternehmen profitieren ohne zurückzugeben. Das LLM-Argument ändert die Skala, aber nicht die Struktur. Und ein archiviertes Gem ändert an der Skala nichts, es ist eine symbolische Geste.

Lena Vogel: Und die Gegen-Gegen-Position: Symbole haben Wirkung, wenn sie genug Leute gleichzeitig machen. Die Frage ist einfach, ob das ein koordiniertes Problem ist oder individueller Frustrationsausdruck. Ich glaube, im Thread war die letzte Position: Es ist beides, und deswegen so schwer zu beantworten.

Felix Hartmann: Und dann noch ein Lichtblick am Ende dieses Blocks, der fast schon versöhnlich klingt: Ein Entwickler hat Qwen3-4B feingetunt, um KI-Schreibfallen zu entfernen. Also diese charakteristischen Muster, Em-Dashes, die bestimmte Formulierungen, die den LLM-Fingerabdruck geben.

Lena Vogel: Und die Zahlen sind schön: Der Slop-Score, also das Maß für KI-Gelumpe, fiel von 121 auf 12,5. Und die Faktentreue blieb bei 30 von 30 Fragen korrekt. Also es ist gelungen, den Stil zu reparieren, ohne die Intelligenz zu beschädigen.

Felix Hartmann: Und das ist ein hübscher Kontrapunkt zum Ruby-Thread. Der eine sagt: Das Commons wird abgebaut. Der andere sagt: Ich nehme ein Open-Weight-Modell und mache es besser für meinen Anwendungsfall. Beide Positionen existieren gleichzeitig, und beide haben etwas wahr.

Lena Vogel: Und das führt uns direkt in den Werkbank-Block, den praktischen Teil. Denn da geht es genau um die Frage: Wie arbeitet man mit diesen Systemen konkret? Und da ist ein Bericht, der im Thread sehr gut ankam: Ein Praktiker steuert mehrere Claude-Code-Agenten über tmux.

Felix Hartmann: Die Mechanik: tmux-Sessions, send-keys, um den Agenten Prompt zu schicken, capture-pane, um die Ausgabe zurückzulesen. Also im Kern ist tmux die Schnittstelle zwischen Mensch und Agent.

Lena Vogel: Und dann die wichtige Einschränkung: Ab vier Agenten wird es eng. Das ist die eigentliche Erkenntnis, die im Thread diskutiert wurde. Die Grenze ist nicht technisch, sie ist kognitiv. Der Mensch kann nicht mehr als drei oder vier parallele Agenten-Konversationen sinnvoll beaufsichtigen.

Felix Hartmann: Einige Kommentierende haben gesagt: Das ist ja der Punkt, eigentlich sollte der Agent die Agenten beaufsichtigen. Also ein Orchestrator-Agent, der die Session-Verwaltung übernimmt, und der Mensch reviewt nur das Ergebnis.

Lena Vogel: Andere haben kontert: Genau das ist der Traum, der immer wieder scheitert. Wenn der Orchestrator selber ein LLM ist, bekommst du die Fehler der Unter-Agenten plus die Fehler des Orchestrators. Multiplikation, nicht Addition. Und der Thread endete da relativ offen.

Felix Hartmann: Was ich gut fand, war der pragmatische Mittelweg einiger Kommentare: Tmux ist gut genug, solange du nur drei Agenten hast, und ab vier brauchst du dann wirklich Tooling. Das ist ein anti-hype-Standpunkt, der mir symathisch war.

Lena Vogel: Dann, Hardware. Es gibt einen Bericht über Arch Linux ARM auf dem ASUS ProArt P16, einem ARM-Laptop mit RTX Spark und 128 GB RAM.

Felix Hartmann: Und die Key-Nummer: 116 GB sind für CUDA sichtbar. Das ist der Vorteil von ARM-Laptops mit Unified Memory, du kannst den GPU fast den ganzen Speicher geben. Auf einem klassischen x86-Laptop mit dedizierter GPU wärst du da bei 8, 16, 24 GB.

Lena Vogel: Das ist praktisch die gleiche Philosopie wie bei einem Mac Studio, nur mit Linux drauf. Und die zweite Zahl: Die CPU-Leistung schlägt Windows teilweise. Also, gleiche Hardware, anderes Betriebssystem, und Linux ist schneller. Das ist nicht überraschend, aber es ist schön, es dokumentiert zu sehen.

Felix Hartmann: Die Kritik im Thread war wie immer bei Linux auf Laptops: Battery Life, Treiber-Feinheiten, Suspend-Verhalten. Also es funktioniert, aber es ist Arbeit. Der Vergleich im Thread war: Du kaufst dir für das Geld Unix-Erfahrung dazu, du kaufst dir keine Konsumerfahrung.

Lena Vogel: Dann, der nächste Werkbank-Post: Mac.apk. Ein Projekt, das Android-Apps nativ auf Apple Silicon laufen lässt, ohne Emulator, ohne VM.

Felix Hartmann: Und das ist möglich, weil Macs und moderne Android-Geräte beide auf ARM basieren. Die Instruktionssätze sind nah verwandt. Man muss also nicht emulieren, man muss nur die Systemaufrufe und Libraries übersetzen. Und das Ergebnis: 51 von 65 getesteten Apps laufen voll spielbar. Im Alpha-Stadium.

Lena Vogel: Die Diskussion im Thread war kurz, aber interessant: Einige sahen das als "Ende der Virtualisierung auf ARM", andere haben zu Recht gesagt: Der alte Witz "ARM ist ARM" stimmt nur teilweise, es gibt hundert Subtle Differences in Memory-Ordering, Cache-Verhalten, GPU-Treibern. Und genau deshalb sind 14 von 65 nicht lauffähig.

Felix Hartmann: Und das Fehlende ist meist die GPU-Übersetzung. CPU-Code ist portabel, GPU-Code mit Metal oder Vulkan ist Hardware-spezifisch. Das ist die harte Grenze des Projekts.

Lena Vogel: Dann, noch ein Werkbank-Post, und der ist für Infrastruktur-Leute wirklich spannend: KiviDB. Eine Rust-Datenbank, Redis-kompatibel, AGPL-lizenziert.

Felix Hartmann: Und die Benchmark: 21,2 Millionen gepipelined GETs pro Sekunde, gegenüber 9,1 Millionen von Dragonfly auf 32 Kernen. Also mehr als doppelt so schnell wie einer der bisherigen Speed-Könige.

Lena Vogel: Und der Thread hat das kritisch zerlegt, wie man das bei solchen Benchmarks tun muss. Die Hauptfrage: Was genau ist gepipelined, was ist der Setup, sind das gleiche Workloads? Ein Benchmark-Vorsprung von Faktor 2 kann an Antworten liegen, an Netzwerk-Stacks, an Kernel-Tuning.

Felix Hartmann: Aber selbst mit Vorsicht ist das bemerkenswert, weil Dragonfly bisher als der Performance-König galt. Und KiviDB hat auch noch Vektorsuche eingebaut, also das ist kein Spielprojekt, das ist ein ernsthafter Angriff auf den Markt.

Lena Vogel: Und die Lizenz ist ein eigener Diskussionspunkt. AGPL ist für Firmen manchmal ein Ausschlusskriterium. Also das ist bewusst gewählt, und die Kommentare im Thread haben das gespiegelt: Die einen sagen, AGPL schützt das Projekt vor Cloud-Anbietern, die anderen sagen, AGPL schließt Adoption aus. Das ist der ewige Konflikt.

Felix Hartmann: Und dann noch ein Post, der theorethischer ist, aber die Werkbank-Leute begeistert hat: One-Hash-Bloom-Filter, von Lu und Kollegen.

Lena Vogel: Klassische Bloom-Filter brauchen k unabhängige Hash-Funktionen. Die Idee hier: Du nimmst eine einzige Hash-Funktion und schneidest den Output in k coprime Partitionen. Das ist billiger und cache-freundlicher.

Felix Hartmann: Und der Proof of Adoption ist stark: Das läuft seit neun Monaten in Blueskys gloom, also in Produktion. Das ist keine Paper-Mathematik, das ist erprobt.

Lena Vogel: Und in der Diskussion war der Tenor: Das ist ein schönes Beispiel für die Art von Forschung, die HN liebt. Kleine clevere Idee, formell begründet, sofort nützlich. Kein Startup-Story-Momentum, einfach gutes Engineering.

Felix Hartmann: Und es gibt einen versteckten thematischen Link zurück zum PostgreSQL-Block: Auch hier geht es um die Frage, wie viel Verifikation genug ist. Der Bloom-Filter wurde neun Monate in Produktion getestet. Das ist die gleiche Philosophie wie "Tests statt Zeilen-Review": Vertrauen entsteht durch Ausführung, nicht durch Lesen.

Lena Vogel: Genau, und das leitet über zum nächsten Block: Betriebssysteme und Plattform-Müdigkeit. Da gibt es ein klassisches Trio: OpenBSD, Linux, und irgendwo dazwischen GitHub.

Felix Hartmann: Also OpenBSD 8.0. Und die Key-Story ist, dass die DRM-Unterstützung, also die moderne Grafik-Treiber-Architektur, jetzt auf die Linux-6.18.y-Basis gezogen wurde. Das ist ein_PATTERN, das OpenBSD seit Jahren verfolgt: Man portiert die Linux-Treiber-Schicht, statt sie selbst zu entwickeln.

Lena Vogel: Das hat einen sehr pragmatischen Grund: GPU-Treiber sind gigantisch, und keine kleine Community kann das selbst halten. Indem man die Linux-Basis nachzieht, kriegt man Intel Arc Support, also die aktuellen GPUs. Das ist für OpenBSD-Verhältnisse ein großes Stück Nutzerfreundlichkeit.

Felix Hartmann: Und dann noch zwei Highlights: Clang/LLVM 22 als Basis-Compiler. Und vmm, der eingebaute Hypervisor, schafft jetzt bis zu 64 vCPUs. Das ist für ein Projekt, das traditionell minimalistisch ist, ein Hinweis, dass sie auch Server-Workloads ernst nehmen.

Lena Vogel: Und dann, die eigentliche Überraschung: Wine läuft jetzt auf OpenBSD. Also, die Windows-Kompatibilitätsschicht wurde portiert.

Felix Hartmann: Und zwar so gut, dass Witcher 3 REMASTER läuft. Das ist 64-bit-Windows-Apps. Das war technisch kompliziert, weil Wine auf Linux bestimmte Kernel-Features benutzt, die OpenBSD nicht hat. Die Lösung umfasst Dinge wie %gs-Emulation, also ein Segment-Register, das Wine braucht.

Lena Vogel: Was nicht geht: 32-bit. Das ist die klassische Grenze, die viele Projekte inzwischen akzeptieren. Die Kommentare im Thread waren deswegen geteilt: Die einen haben gefeiert, die anderen haben gesagt: Nett, aber wer braucht Windows-Apps auf OpenBSD? Die Antwort der ersten Fraktion: Es geht nicht um den Use Case, es geht um die Machbarkeit und die Portabilität der Codebasis.

Felix Hartmann: Und dann Linux 7.3. Und da gibt es eine Zahl, die im Thread wirklich Aufsehen gemacht hat: 18.765 Commits von 3.021 Entwicklern. Das ist ein Rekord.

Lena Vogel: Und dann ein Kuriosum, das ich erwähnen muss, weil der Thread es natürlich sofort zerlegt hat: failfs. Ein Dateisystem, in dem alle Dateioperationen fehlschlagen. Das ist ironisch gemeint und hat einen Test-Zweck, aber die Kommentare haben es natürlich sofort in alle Richtungen gedeutet: "endlich ein Dateisystem für die Produktion", und so weiter.

Felix Hartmann: Es gibt auch fchroot, ein neues Feature, und die allgemeine Botschaft ist: Linux wächst weiter, auf allen Ebenen, und die Community ist riesig. Das ist die gesunde Gegenseite zur Plattform-Müdigkeit, von der wir gleich reden.

Lena Vogel: Und genau diese Müdigkeit kommt mit GitHub. Es gab Performance-Probleme bei Actions, Pages und Webhooks. Workflows laufen langsam, Webhook-Delivery ist verzögert.

Felix Hartmann: Seit dem 19. Oktober ist es gebessert, aber es wird weiter beobachtet. Und das ist der eigentliche Punkt im Thread: Es ist nicht die Ausfallzeit, es ist die Häufung. GitHub hatte in den letzten Monaten mehrere solcher Episoden, und der Tenor war: Wir bauen kritische Infrastruktur auf eine Plattform, die uns immer wieder mal im Stich lässt.

Lena Vogel: Die Diskussion hat dann gedreht: Was ist die Alternative? Forgejo, Gitea, selbst-gehostete Lösungen. Und dann kamen die Gegenargumente: Die Network-Effekte von GitHub sind enorm, und die Alternativen sind funktional nicht gleichauf. Also bleibt man, aber man beschwert sich.

Felix Hartmann: Und das ist die Definition von Plattform-Müdigkeit: Du bleibst, aber du fängst an, Ausweichpläne zu schreiben. Und das ist auch ein Thema, das zum nächsten Block passt, denn da geht es um Institutionen, deren Vertrauenswürdigkeit genau in Frage gestellt wird.

Lena Vogel: Also, der Block über Überwachung, Validierung und Vertragsfragen. Und der startet mit einer Geschichte, die ziemlich beunruhigend ist: Ein IPinfo-Scan hat vor dem Oktober-2026-Angriff 1.331 offengelegte französische Danfoss-Kühlschrank-Dashboards gefunden. 85 Prozent davon hatten bekannte Schwachstellen.

Felix Hartmann: Und nach dem Angriff sind die meisten offline. Also, der Angriff hat faktisch die Infrastruktur zerstört oder die Betreiber zum Abschalten gezwungen.

Lena Vogel: Was das so beunruhigend macht: Das sind keine Server-Räume, das sind physische Anlagen. Kühlketten, Supermärkte, Lagerhäuser. Wenn die Dashboards offen im Internet hängen, ist das nicht nur ein Datenschutzproblem, sondern ein kritische-Infrastruktur-Problem.

Felix Hartmann: Die Kommentare im Thread haben dann das eigentliche Problem benannt: Diese Geräte werden gekauft, installiert und vergessen. Kein Patch-Zyklus, kein Owner für Security, kein Pflicht-Update. Die Industrie verkauft IoT-Geräte mit einer Lebensdauer von zehn Jahren und einer Security-Attention-Spanne von null.

Lena Vogel: Und es gibt eine dunkle Verbindung zu dem Plex-Thread von vorhin. Genau das gleiche Muster: Gepatchte Lücke, kein Auto-Update, offenes Internet. Bei Plex ist es ein Crypto-Miner, bei Kühlhäusern ist es ein Angriff auf Lebensmittelinfrastruktur.

Felix Hartmann: Und dann, eine Geschichte, die eine politische Dimension hat: In Savannah hat ein Polizist sein Flock-Konto einem Ehepartner geliehen, der ICE-Beamter ist. Und der hat über sechs Bundesstaaten 983 Suchen gemacht.

Lena Vogel: Zur Einordnung: Flock ist das widespread Netzwerk von automatischen Kennzeichen-Lesern. Die Daten sind eigentlich für lokale Polizeiarbeit. Und hier wurde ein privates Konto genutzt, um landesweit nach Fahrzeugen zu suchen.

Felix Hartmann: Der Beamte hat angegeben, es sei um die Verfolgung von Personen mit Arrest-Warrants gegangen. Aber der Polizist wurde trotzdem entlassen. Und im Thread war die Diskussion dreigeteilt.

Lena Vogel: Die erste Fraktion sagte: Das ist ein Kontrollversagen. Ein Konto ist ein Konto, und wenn der Zugang nicht personengebunden und auditiert ist, ist das System per Design missbrauchbar. Die zweite Fraktion sagte: Das Ziel war legitim, also wieso entlässt man jemanden für effiziente Polizeiarbeit? Und die dritte Fraktion, die die größte war, sagte: Es geht nicht um den Einzelfall, sondern um die Struktur.

Lena Vogel: Flock ist ein landesweites Tracking-Netz, das von Hunderten von kleinen Behörden betrieben wird, ohne föderale Kontrolle.

Felix Hartmann: Und das ist die eigentliche Frage des Threads: Brauchen wir für Datensammlungs-Netzwerke eine Föderal-Governance? Weil die lokalen Regeln nicht reichen, wenn die Daten bundesweit fließen.

Lena Vogel: Dann, ein Lichtblick in diesem Block: Let's Encrypt. Die haben zwei neue Remote-Standorte für die Domain-Validierung hinzugefügt, als Reaktion auf die BR-Pflicht zur multi-perspective-Validierung, die am 15. Dezember 2026 in Kraft tritt.

Felix Hartmann: Kurz erklärt: Bei der Validierung prüft Let's Encrypt, dass du die Domain kontrollierst. Wenn ein Angreifer das Routing manipuliert, also einen BGP-Hijack macht, kann er die Validierung abfangen. Mit mehreren Perspektiven aus verschiedenen Netzwerken wird das viel schwerer.

Lena Vogel: Die Kommentare im Thread waren zustimmend. Let's Encrypt ist in einer guten Position, weil sie die Infrastruktur haben, um das umzusetzen. Die Frage der kleineren CAs, die das auch leisten müssen, blieb offen. Es ist eine regulatorische Pflicht, die strukturell kleinere Anbieter benachteiligt.

Felix Hartmann: Und dann, der letzte Post in diesem Block: Verisign. Die haben das Monopol auf .com und werden beschuldigt, die Preise unfair hochgetrieben zu haben. In einer Sammelklage, an der ICANN mitveranstaltet ist.

Lena Vogel: Die Zahlen: Eine .com-Domain kostet im Einkauf etwa 3 Dollar. Und die Preise sind seit 2021 um mehr als 30 Prozent gestiegen.

Felix Hartmann: Und das ist die Kernfrage des Threads: Verisign hat ein Vertragsmonopol, vergeben von ICANN, und nutzt das, um Preise zu erhöhen, ohne dass Wettbewerb das begrenzt. Die Verteidigung von Verisign wäre vermutlich: Wir investieren in Infrastruktur und Sicherheit. Die Klage behauptet, das Verhältnis passt nicht.

Lena Vogel: Und im Thread gab es eine interessante Neben-Diskussion: .com ist ein Legacy-Produkt, und die Preise zu erhöhen, ist möglich, weil die Migration zu alternativen TLDs langsam ist. Es ist ein gewisser Kontrast zu allem, was wir heute besprochen haben: Das ist kein Tech-Problem, sondern ein Vertrags- und Regulierungsproblem.

Felix Hartmann: Und das leitet direkt zum letzten Block über: Vertrauen und Governance. Denn hier geht es nicht um Tech-Details, sondern um die Frage: Wer kontrolliert die Kontrolleure?

Lena Vogel: Also, der erste Post: Anthropics IPO stößt auf Skepsis wegen des Long-Term Benefit Trust. Das ist ein fünf-köpfiges Gremium, das den Board formt und große Schritte blockieren kann.

Felix Hartmann: Und die Skepsis im Thread ging in zwei Richtungen. Die erste: Das ist ungewöhnlich, und Investoren mögen keine ungewöhnlichen Governance-Strukturen. Wer hat das letzte Wort, wenn das Gremium entscheidet? Ist das demokratisch legitimiert? Wer wählt die fünf?

Lena Vogel: Die zweite Richtung war fast das Gegenteil: Die Kommentatoren sagten, eigentlich ist das ein mutiger Versuch, das Short-Term-Denken des Aktienmarkts zu kontern. Ein IPO setzt normalerweise einen enormen Druck auf schnelle Gewinne frei, und ein Gremium, das das bremsen kann, ist ein interessantes Experiment.

Felix Hartmann: Und die dritte Fraktion, die die skeptischste war, sagte: Das ist symbolic governance. Es sieht aus wie eine Bremse, aber die tatsächliche Macht bleibt bei den Leuten, die das Gremium besetzen. Wenn die fünf mit dem Unternehmen sympathisieren, ist es eine Bügelfalte im Statut.

Lena Vogel: Und die offene Frage ist praktisch: Wird der IPO-Preis das reflektieren? Und wenn ja, in welche Richtung? Das wird sich in den nächsten Monaten zeigen.

Felix Hartmann: Und dann, ein Story-Block, der überraschend gut im Thread angekommen ist, obwohl er nicht Tech ist: Das Eier-Kartell.

Lena Vogel: Die US-Justiz wirft den drei größten Eierproduzenten vor, über abgestimmte Gebote die Preise hochgetrieben zu haben. Also, die Eier-Preis-Krise, die in den letzten Jahren so groß war, war möglicherweise teilweise organisiert.

Felix Hartmann: Und der Tenor im Thread war: Das ist die Form von Kartell, die klassische Antitrust-Theorie perfekt abbildet. Oligopol, identische Preis-Bewegungen, keine Kosten-Erklärung. Die Kommentare haben teilweise zynisch gefrotzelt: "Das War-Ding war natürlich das Huhn-Preis-Kartell", aber darunter war die ernsthafte Diskussion: Die Regulierer sind langsam, die Beweislast ist hoch, und die Strafen sind klein im Verhältnis zum Gewinn.

Lena Vogel: Und die Verbindung zu unserer heutigen Diskussion: Es ist eine Vertrauensfrage. Ob es Algorithmen sind, die Preise setzen, oder Kartelle, die Gebote abstimmen, das Resultat ist für den Konsumenten gleich: Er zahlt zu viel und kann nicht nachvollziehen, warum.

Felix Hartmann: Und die Meta-Proteste in Brasilien, die wir schon im Security-Block angesprochen haben, passen hier auch nochmal rein: Es geht um Vertrauen in Plattformen und die Frage, wer das überprüfen kann.

Lena Vogel: Und die letzten beiden Punkte, die wir kurz verknüpfen wollen, sind die kompromittierten Kühlschrank-Dashboards und die ungepatchten Plex-Boxen. Beide zeigen, wie viel Vertrauen und Aufmerksamkeit Tech-Systeme verbrauchen. Ein Kühlhaus hat kein Security-Team. Ein Plex-Server zu Hause hat keinen Admin. Und die Systeme sind trotzdem im Internet.

Felix Hartmann: Und wenn man den ganzen Tag so durchgeht, von Mercury 3 bis zum Eier-Kartell, dann ist die eigentliche Frage: Wer hat die Zeit und die Aufmerksamkeit, all das zu verifizieren? Benchmark-Siege, Security-Patches, Algorithmus-Fairness, Kartell-Anklagen. Das ist zu viel für eine Person.

Lena Vogel: Ich glaube, das ist auch die eigentliche Botschaft der heutigen Kommentare in den Threads: Die Individualverantwortung stößt an Grenzen. Wir brauchen bessere Defaults, auto-updates, maschinenprüfbare Fairness, kartellrechtliche Durchsetzung. Und auf individueller Ebene: Tests statt Zeilen-Review, und plattformübergreifende Skepsis bei Benchmarks.

Felix Hartmann: Und damit sind wir am Ende. Danke, dass du da warst. Wir sind nächste Woche wieder dabei, und bis dahin: Halte deine Agenten-Instanzen zu, update dein Plex, und glaube keinen Benchmarks, die du nicht selbst reproduziert hast.

Lena Vogel: Das war's von uns. Bis zum nächsten Mal.