Willkommen zu allesnurgecloud.com – Ausgabe #236

in der Security Ecke ist in dieser Woche wieder viel passiert, man kommt kaum hinterher – vielleicht nimmt das Tempo doch schneller zum, als ich noch vor ein paar Wochen spekuliert hatte. Nach CopyFail in Linux kam die Woche Dirty Frag dazu, NGINX Rift dann am Donnerstag (siehe Artikel) , in Next JS gab es diverse Advisories und die neue GitLab Version 18.11.3 hatte nicht wie sonst 2,3 Security Fixe, sondern über 20.
Und vermutlich kommt bis morgen – ich schreibe heute am Samstag – noch etwas dazu.

In den USA sollen 50.000 Einwohner nahe dem Lake Tahoe nun irgendwie schauen, woher sie den Strom in Zukunft bekommen – die neu geplanten Datacenter haben wohl Vorfahrt. Ansonsten wollen auch 7 von 10 US-Amerikanern kein Datacenter vor ihrer Haustüre haben. Vermutlich brauchen wir deshalb die Datacenter im Space, da sie hier keiner mehr haben will. Google hat dazu nun einen Deal mit SpaceX beschlossen – „Project Suncatcher“ heisst das dann. Oder liegt es nur am 6 % Anteil, den Alphabet an SpaceX hat?

Positive News aus Deutschland – Dank einer von SAP geführten Investmentrunde in N8n wird das Berliner Start-up jetzt mit 5,2 Milliarden US Dollar bewertet (News bei Golem). Der N8n Gründer Jan Oberhauser hält wohl noch 46 % am Unternehmen – Herzlichen Glückwunsch!

So, und nun viel Spaß mit Ausgabe #236.

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 172 habe ich mit Marc Nilius von WP-Wartung24 über sein WordPress-Wartungsunternehmen aus dem Westerwald gesprochen. Mit zehn Leuten betreut sein Team rund 800 WordPress-Websites in der laufenden Wartung – größter unabhängiger Anbieter im DACH-Raum. Wir reden über den 50.000-Euro-Switch in die Vollzeit-Selbstständigkeit, den großen Plugin-Backdoor-Skandal vom April 2026, WordPress 7 mit den neuen KI-Konnektoren und Marcs Plan, sich 2026 stärker zu diversifizieren. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.

Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).

allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

Mythos bei curl: Marketing trifft gepflegten Codebase

curl-Maintainer Daniel Stenberg zieht in seinem Blog eine nüchterne Bilanz zu Anthropics als „dangerously good“ vermarktetem Security-Modell Mythos – nur wenige Tage nachdem TechRadar Mozillas 423 Firefox-Bugfixes im April 2026 als Beweis für die Leistungsfähigkeit des Modells gefeiert hatte. Über das Project-Glasswing-Programm bekam curl via Linux Foundation Zugang zu einem Scan über 178.000 Zeilen Code. Der Report meldete fünf bestätigte Schwachstellen – nach Prüfung durch das curl-Security-Team blieben drei False Positives, ein normaler Bug und genau ein Low-Severity-CVE, der mit curl 8.21.0 Ende Juni veröffentlicht wird.

Der Unterschied zwischen Mozillas Erfolgsmeldung und Stenbergs Befund liegt nicht am Modell, sondern am Setup. Mozilla hat ein eigenes „Harness“ gebaut, das Mythos gezielt mit verdächtigen Dateien füttert und Testfälle fürs Fuzzing generieren lässt – das Modell sucht also nicht blind, ein menschliches Team kuratiert die Eingabe. Bei curl trifft Mythos dagegen auf einen Codebase, in dem laut Stenberg jede Zeile im Schnitt 4,14-mal umgeschrieben wurde, der mit OSS-Fuzz, Coverity, CodeQL und mehreren bezahlten Audits durchkämmt ist und in dem Defensiv-Patterns wie curlx_str_number mit explizitem Max bei jedem Numeric-Parse die produktiven Bug-Klassen systematisch schließen. Das räumt der Mythos-Report in seiner eigenen Methodology sogar selbst ein.

Mythos schneidet bei curl nicht erkennbar besser ab als die bisher eingesetzten AI-Tools AISLE, Zeropath oder OpenAI Codex Security – die zusammen in den letzten 8 bis 10 Monaten zwei- bis dreihundert Bugfixes ausgelöst haben. AI-Analyzer finden mehr als klassische Tools, erklären sauberer und liefern oft Patch-Vorschläge gleich mit. Aber sie entdecken keine neuen Fehler-Kategorien, sondern lediglich neue Instanzen alter Probleme. Stenberg empfiehlt trotzdem jedem Projekt, solche Tools einzusetzen – sonst hätten die Angreifer den Vorsprung. Den „dangerously good“-Hype rund um Mythos hält er aber für das, was er ist: Marketing.

Naja, wir können das alles ja gar nicht so richtig beurteilen, haben ja keinen Zugriff…

Mythos finds a curl vulnerability

---

NL: Forgejo statt GitHub

In einer ungewöhnlichen Konstellation kommen ein niederländisches Ministerium und ein einzelner DevOps-Berater zur gleichen Schlussfolgerung – innerhalb weniger Tage. Am 27. April 2026 hat das niederländische Innenministerium code.overheid.nl gestartet – eine selbst gehostete Forgejo-Instanz für den Quellcode der Regierung. Eine Woche später migrierte Jorijn Schrijvershof seinen Code auf dieselbe Plattform und liefert die institutionelle Entscheidung gleich im Detail nachgereicht.

Beide schreiben über dasselbe Muster: Outages sind nicht der Grund. Zwar hat GitHub zwischen Mai 2025 und April 2026 257 Incidents verzeichnet, davon 48 als „major“ – aber das ist Symptom, nicht Ursache. Strukturell sitzen drei Punkte tiefer. GitHub hat seit August 2025 keinen eigenen CEO mehr; Thomas Dohmke ging, kein Nachfolger – stattdessen wanderte GitHub in Microsofts CoreAI-Division unter Julia Liuson. Seit dem 24. April 2026 fließen Copilot-Interaktionsdaten aus Free-, Pro- und Pro+-Tarifen per Default ins Modelltraining – Opt-out nur per Account, kein Repository-Schalter. Und CLOUD Act und FISA 702 gelten weiter: die Aussage von Microsoft-Justiziar Carniaux vor dem französischen Senat, er könne US-Zugriff auf EU-Daten nicht ausschließen, gilt genauso für GitHub-Repositories.

Bemerkenswert ist die Forge-Wahl: nicht GitLab, obwohl das die naheliegende Option wäre. Die EU-Kommission setzt auf GitLab, Deutschlands openCode ebenfalls. Project-Manager Boris Van Hoytema begründet die Entscheidung damit, dass Forgejo vollständig Open Source sei – ohne Open-Core-Split, ohne Enterprise-Tier-Gating. Forgejo läuft seit der Abspaltung von Gitea im Dezember 2022 unter dem Codeberg e.V., einem Berliner Verein mit gewähltem Vorstand. In Ausgabe 145 hatte ich Forgejo bereits als Linktipp – die institutionelle Adoption macht daraus eine ernsthafte Plattform-Wahl.

Why I’m leaving GitHub for Forgejo

---

---

GitLab Act 2: Restrukturierung statt Positionierung

Während der vorherige Artikel zeigt, wie Entwickler GitHub den Rücken kehren und auf Self-Hosting setzen, hätte GitLab gerade jetzt einen Moment für die naheliegende Positionierung gehabt – stabile, transparente Open-Core-Alternative zum AI-getriebenen GitHub-Chaos. Stattdessen verkündet CEO Bill Staples in einem auffällig langen Brief genau das Gegenteil: „GitLab Act 2″ – Restrukturierung im Namen der „agentic era“, Abbau in bis zu 30 % der Länder, drei Management-Layer raus, R&D zerlegt in rund 60 kleinere Teams. Konkrete Headcount-Zahlen folgen erst am 2. Juni im Earnings Call. Die Börse hat trotzdem reagiert: 8 % Kursrutsch nach Handelsschluss, von 52 auf 26 USD im Zwölfmonatstrend.

Bemerkenswert ist das Werte-Reframing. Das alte CREDIT-Framework (Collaboration, Results for Customers, Efficiency, Diversity/Inclusion/Belonging, Iteration, Transparency) wird durch „Speed with Quality, Ownership Mindset, Customer Outcomes“ ersetzt. Auf Hacker News bringt es User Animats trocken auf den Punkt: „work harder, not smarter, and no more DEI.“ Dass ausgerechnet Transparency rausfällt – jener Wert, der GitLab mit dem öffentlichen Handbuch berühmt gemacht hat (siehe Ausgabe 114) – ist für eine Firma, die gleichzeitig ein „transparentes Restructuring“ verspricht, mindestens ironisch.

Inhaltlich setzt GitLab auf vier Architektur-Wetten: Git selbst für Maschinen-Last neu bauen, CI/CD in eine Agent-Orchestration verwandeln, ein Connected-Data-Modell als Kontext-Layer für Agenten, Governance als Plattform-Service. Dazu ein neues Pricing-Modell – Subscription plus Consumption für Agent-Arbeit. Die Vision ist konsistent, der Zeitpunkt merkwürdig: FY26 schloss mit 26 % Wachstum bei 955 Mio. USD, die FY27-Guidance liegt bei nur noch 15–17 %. Atlassian hatte im März 2026 mit ähnlicher AI-Begründung 10 % entlassen – das Muster wiederholt sich.

Schade – ein GitLab, das auf Stabilität, Souveränität und Self-Hosting gesetzt hätte, wäre die deutlich interessantere Geschichte gewesen.

GitLab Act 2

---

Bitwarden: Stiller Umbau Richtung Exit?

Der Open-Source-Passwortmanager Bitwarden vollzieht aktuell mehrere Veränderungen, die Jared Newman bei Fast Company zusammengetragen hat – und die in Summe ein klares Muster ergeben.

Im Februar wechselte Langzeit-CEO Michael Crandell in eine Beraterrolle, ohne Ankündigung der Firma. Sein Nachfolger Michael Sullivan war zuvor CEO bei Acquia und Insightsoftware und wirbt auf LinkedIn explizit mit Erfahrung in „all facets of mergers and acquisitions“ sowie Verbindungen zu Vista Equity Partners, Hg und TA Associates. Im April ging auch CFO Stephen Morrison, ersetzt durch den Ex-InVision-CEO Michael Shenkman.

Parallel verschwand der Hinweis „Always free“ von der Produktseite des persönlichen Passwortmanagers, und das Werte-Akronym GRIT wurde umgewidmet: aus „Gratitude, Responsibility, Inclusion, Transparency“ wurde „Gratitude, Responsibility, Innovation, Trust„. Nach öffentlichem Druck stellte Bitwarden „Always free“ auf der Pricing-Seite wieder her – die Produktseite bleibt unverändert. Zuvor war bereits der Premium-Plan klammheimlich von 10 auf 20 Dollar verdoppelt worden.

Auf Hacker News bringt es User chipotle_coyote auf den Punkt: Die Kombination aus PE-erfahrenem CEO, abgeschwächtem Free-Plan und entschärften Werten schreie danach, dass Bitwarden für einen Verkauf vorbereitet werde. Bitwardens Chief Customer Officer Gary Orenstein dementiert: Man suche keinen Käufer.

Bereits in Ausgabe 163 gab es Irritationen rund um die Open-Source-Linie von Bitwarden – die aktuellen Signale fügen sich in dieses Bild.

Und nun? wie lange wird wohl „Vaultwarden“ noch funktionieren, bevor es mit den Apps nicht mehr läuft?

Bitwarden scrubs ‘Always free’ and ‘Inclusion’ values from its website as longtime execs step down

---

AI findet den nächsten nginx-Bug: NGINX Rift (CVE-2026-42945)

Passend zum ersten Beitrag dieser Ausgabe über Anthropics Mythos-Scanner liefert die Sicherheitsfirma Depthfirst gerade ein konkretes Beispiel für autonomes AI-Schwachstellen-Auffinden: Der 18 Jahre alte Heap-Overflow CVE-2026-42945 im ngx_http_rewrite_module von nginx wurde laut Eigenaussage komplett autonom durch die Depthfirst-Plattform entdeckt. F5 hat den Bug bestätigt und am 13. Mai gepatcht, Ubuntu folgte einen Tag später.

Der CVSS-Score variiert je nach Quelle – Depthfirst gibt 9.2 an, Ubuntu 8.1 –, die Auswirkung ist in beiden Fällen Remote Code Execution im Worker-Prozess ohne Authentifizierung. Auslöser ist ein verbreitetes Konfigurationsmuster: eine rewrite-Direktive mit unbenannten Regex-Captures ($1, $2) und einem Replacement, das ein Fragezeichen enthält, gefolgt von einer weiteren rewrite-, if– oder set-Direktive im selben Scope. nginx berechnet das Ziel-Buffer mit einer Escaping-Annahme und schreibt mit einer anderen – jedes +, % oder & im Capture expandiert auf zwei Bytes, der Write läuft über die Allokation hinaus.

Betroffen sind nginx OSS 0.6.27 bis 1.30.0 und nginx Plus R32 bis R36. Patches: nginx 1.31.0 oder 1.30.1 (OSS), R36 P4 bzw. R32 P6 (Plus). Ubuntu hat 26.04, 25.10, 24.04 und 22.04 versorgt; 20.04 und älter sind noch in Bewertung. Ein Reboot ist nicht nötig, ein nginx-Restart genügt, damit die Worker mit dem gepatchten Binary neu laden.

Wer nicht sofort upgraden kann, ersetzt im verwundbaren Pattern die unbenannten Captures durch named captures: statt rewrite ^/users/([0-9]+)/...$ /profile.php?id=$1 last; einfach rewrite ^/users/(?[0-9]+)/...$ /profile.php?id=$user_id last;. Damit ist der konkrete Bug entschärft, bis das Upgrade ansteht. Bei der Anzahl Server, die nginx mit rewrite-Regeln betreiben, wird das in vielen Operations-Teams diese Woche der wichtigste Punkt auf der Liste sein.

NGINX Rift

---

97.000 USD AWS-Rechnung: Root Account ohne MFA

Klassiker mit neuem Inhalt: Ein Frischabsolvent meldet auf r/aws, dass binnen 48 Stunden eine AWS-Rechnung über 97.000 USD auf ihn zugekommen ist – sein bisheriger Spend lag bei rund 1.700 USD. Der Kostenpunkt: Anthropic Claude Sonnet via Bedrock. Genutzt hat er das Feature nie selbst, er hatte den Modell-Zugriff nicht einmal angefordert.

Das Muster ist altbekannt, der Inhalt ist neu. User Latter-Ad6360 bringt es trocken auf den Punkt: „It used to be bitcoin mining, now it’s AI tokens.“ Ein kompromittierter Root-Account ohne MFA oder geleakte Access Keys reichen, und Angreifer schöpfen über Bedrock in 48 Stunden ab, wofür ein 200-Personen-Team laut Reddit-User BennyTheSen rund 70–80k pro Monat zahlt. Die nötige Token-Last – ein Kommentator schätzt 2 Millionen Tokens pro Minute über zwei Tage – sagt einiges über Bedrocks Default-Quota-Limits.

Was AWS dem nichts entgegensetzt, ist seit Jahren dieselbe Beschwerde: kein Kill-Switch bei Budget-Überschreitung. Budget-Alerts benachrichtigen, stoppen aber nichts. Wer ihn will, baut ihn selbst über Lambda, EventBridge und IAM-Policy-Detach – nichts, was ein neuer Account-Inhaber auf dem Schirm hat. Hobby- und Lern-Accounts tragen damit ein finanzielles Tail-Risk in keinem Verhältnis zum erwarteten Nutzen.

Solche Fälle werden vom AWS-Support meistens erlassen, sofern das Verschulden des Nutzers gering wirkt und MFA nachträglich aktiviert ist. Operativ ist die Mitigation eindeutig: Root-Account mit MFA und langem, abgelegtem Passwort, alltägliche Arbeit ausschließlich über IAM Identity Center, eine Service Control Policy, die Bedrock im gesamten Org-Tree blockt, solange man es nicht aktiv braucht. Bei einem Account ohne diese Maßnahmen ist die Frage nicht ob, sondern wann – und welches Modell gerade en vogue ist.

AWS 97k bill out of nowhere

---

imgproxy v4: Internal Cache und Parallel Downloads

imgproxy ist bei mehreren We-Manage-Kunden im Produktionseinsatz, daher schaue ich auf den v4-Release mit besonderem Interesse. Das Team hat den Release-Zyklus in fünf Blog-Posts zerlegt – hier die Punkte, die für Self-Hosting-Setups wirklich relevant sind.

Internal Cache (Pro) ist das prominenteste neue Feature: ein optionaler persistenter Cache für verarbeitete Bilder, der CDNs als Primär- oder Sekundärcache ergänzt. Unterstützt werden lokales Filesystem, S3-kompatible Storages (inkl. R2 und DigitalOcean Spaces), GCS, Azure Blob Storage und OpenStack Swift. URL-Signatur ist explizit nicht Teil des Cache-Keys, sodass Key-Rotation den Cache nicht invalidiert. Was fehlt: aktive Cache-Invalidierung – man behilft sich mit Cachebustern oder Object-Expiration des Storage-Backends.

Parallel Image Downloading ist die spannendste OSS-Änderung. Bisher lud imgproxy das Quellbild komplett herunter, bevor libvips Hand anlegen durfte. v4 wickelt den HTTP-Stream in einen asynchronen Buffer, aus dem libvips parallel zum Download dekodieren kann – Progressive-JPEG- und PNG-Quellen profitieren am stärksten, langsame Quellen ebenfalls deutlich. Etag und Last-Modified sind jetzt per Default aktiv; der Etag basiert nur noch auf dem Quell-Etag, nicht mehr auf einem teuren File-Hash-Fallback.

Für Security-Hardening interessant: Neue Allow-/Denylists für S3-, GCS-, Azure- und Swift-Buckets (IMGPROXY_S3_ALLOWED_BUCKETS etc.) begrenzen, woher imgproxy Quellbilder ziehen darf. Beim Logging wurde von Logrus auf das Standard-log/slog umgestellt – laut Benchmark dreifache Geschwindigkeit bei einem Zehntel des Memory-Verbrauchs. Logs lassen sich jetzt auch über OpenTelemetry exportieren.

Vor dem Upgrade lohnt ein Blick ins Changelog: deprecated Configs wie IMGPROXY_CONCURRENCY (jetzt IMGPROXY_WORKERS) und sämtliche IMGPROXY_OPEN_TELEMETRY_*-Varianten (jetzt OTEL-Standard-Variablen) sind entfernt. Die offiziellen Linux-Pakete brauchen ab v4 mindestens libc 2.35, weil Build-Base jetzt Ubuntu 22.04 ist.

imgproxy 4.0 Release

---

„Slow the fuck down“ – ein Jahr Coding-Agents

Ein Jahr nachdem die ersten Coding-Agents wirklich produktiv geworden sind, zieht Mario Zechner auf seinem Blog eine ernüchternde Bilanz. Anekdotisch zwar, aber das Muster sei eindeutig: Software werde brüchiger, 98 % Uptime statt 99,9 % würden zur Norm, UIs bekämen Bugs, die jedes QA-Team auffangen würde. Microsoft rede laut Nadella über immer mehr KI-geschriebenen Code – Windows fühle sich auch so an.

Zechners eigentliches Argument ist nicht der Hype, sondern die Mechanik dahinter. Menschen machen Fehler, lernen aber daraus. Agenten lernen out of the box nichts und produzieren denselben Fehler immer wieder, in neuen Kombinationen. AGENTS.md und Memory-Systeme helfen nur, wenn der Mensch den Fehler überhaupt beobachtet. Der zweite Punkt sitzt: Ein Mensch ist ein Bottleneck und kippt nicht in wenigen Stunden 20.000 Zeilen Code in eine Codebase. Ein Schwarm autonomer Agenten schon – ohne Mensch in der Schleife, ohne Schmerzsignal, mit Code-Duplikaten und Cargo-Cult-Architektur, die sich in Wochen aufstauen statt in Jahren wie in klassischen Enterprise-Codebases.

Dazu kommt ein Problem, das Zechner agentic search recall nennt: Der Agent findet beim Durchsuchen großer Codebases nie alles, was relevant wäre. Egal ob via Bash und ripgrep, LSP-Server oder Vector-DB – je größer der Code, desto niedriger der Recall. Genau daraus entstehen die Duplikate und inkonsistenten Abstraktionen, die sich später zur unentwirrbaren Komplexität verdichten. Wenn das Refactoring fällig wird, scheitern dieselben Agenten, weil sie nur lokal sehen.

Zechners Vorschlag ist kein Anti-AI-Manifest. Agents seien gut für abgegrenzte Aufgaben mit geschlossener Eval-Schleife, für ad-hoc-Tools und Rubber-Ducking. Was die Gestalt eines Systems prägt – Architektur, APIs – gehört dagegen per Hand geschrieben. Tippreibung erzeugt das Verständnis, das später beim Debuggen rettet. Tageslimits für agentengenerierten Code, gekoppelt an die eigene Review-Kapazität, sind sein konkreter Hebel. Den AI-Slop-Trend bei Open-Source-Maintainern hatte ich in Ausgabe #200 vorgestellt – Zechner liefert die Innensicht aus laufenden Projekten dazu.

Thoughts on slowing the fuck down

---

Migration in den europäischen Stack

Wie aus einem Tabellenkalkulations-Projekt eine Wertentscheidung wird, zeigt Wimer Hazenberg von Monokai in einem ausführlichen Erfahrungsbericht: Er hat seine komplette Digital-Infrastruktur Richtung Europa migriert – und zwar Tool für Tool.

Die Liste ist beachtlich: Google Analytics → Matomo, Google Workspace → Proton Mail, 1Password → Proton Pass, DigitalOcean → Scaleway, AWS S3 → Scaleway Object Storage, Backblaze → OVHcloud, SendGrid → Lettermint, Sentry → Bugsink, OpenAI → Mistral. Der S3-Umzug per rclone dauerte allein eine Woche durchgehende Synchronisation.

Hazenberg ist dabei ehrlich mit den Trade-offs: Proton Mail kann nicht auf Mail-Inhalte filtern und limitiert Custom Domains auf drei. Bugsink ist eine Bare-Bones-Lösung ohne Performance Monitoring oder Session Replays. OVHcloud ist günstiger als Backblaze, das Control Panel sei aber „a labyrinth“. Vier Ausnahmen bleiben: Cloudflare, Stripe, GitHub (für öffentliche NPM-Packages) und Claude Code statt Mistral als Coding-Assistent – Anthropic sei zwar US-Firma, aber strukturell vertrauenswürdiger als OpenAI.

Auf Hacker News berichtet User TrackerFF passend dazu von einer EU-Konferenz, auf der jedes präsentierende Startup nach EU-Hosting gefragt wurde – ein Reflex, den es vor wenigen Jahren noch nicht gab.

Konkrete Praxis-Berichte wie dieser ergänzen die abstraktere Souveränitäts-Debatte aus Ausgabe 178 und Ausgabe 179 gut – inklusive der unbequemen Erkenntnis, dass auch der bewusste Umstieg an manchen Stellen pragmatische Ausnahmen macht.

Lettermint kannte ich jetzt noch gar nicht, das muss ich mir mal noch anschauen.

How I Moved My Digital Stack to Europe

---

Bambu Lab vs. AGPL: Der Cloud-Zwang eskaliert

Als Bambu-Lab-Kunde mit P2S Combo lese ich Jeff Geerlings neuen Blogpost zur jüngsten Bambu-Eskalation mit besonderem Interesse. Die Vorgeschichte ist bekannt: Bambu hat den firmware-seitigen Wechsel zum Cloud-Default vor rund einem Jahr durchgedrückt, woraufhin Geerling seinen P2S vom Internet trennte, Bambu Studio gegen OrcaSlicer tauschte und ein dauerhaftes Kaufverbot für die Marke aussprach. Bei mir steht der Drucker mit AMS 2 Pro inzwischen ebenfalls deutlich kontrollierter als von Bambu vorgesehen.

Der aktuelle Anlass ist ein Cease-and-Desist gegen den Entwickler des kleinen Forks OrcaSlicer-bambulabs, der – Achtung, Pointe – schlicht den AGPLv3-lizenzierten Code aus Bambu Studio verbatim nutzt, damit Power-User ohne Cloud-Zwang drucken können. Bambu beschuldigt den Entwickler öffentlich der „Identitäts-Impersonation“ und einer „strukturellen Verwundbarkeit“ ihrer Infrastruktur. Geerlings ironischer Konter sitzt: Wenn ein öffentlicher User-Agent-String das einzige Mittel gegen DDoS-Angriffe ist, hat man kein Open-Source-Problem, sondern ein Architekturproblem.

Was den Vorgang besonders bizarr macht: Bambu hat selbst 2022 mit einem eigenen PrusaSlicer-Fork dafür gesorgt, dass Telemetrie der Bambu-User auf Prusa-Servern landete – und Prusa hat damals keinen C&D verschickt. Der Entwickler des Forks hatte zuvor sogar in Bambus eigenem GitHub bei Linux- und Wayland-Problemen geholfen. Louis Rossmann hat dem Dev unterdessen 10.000 USD für die Rechtsverteidigung zugesagt.

Die Lehre ist nicht 3D-Druck-spezifisch. Wer Hardware mit Cloud-Zwang verkauft und gleichzeitig AGPLv3-Code nutzt, kann nicht gleichzeitig den Lizenztext ignorieren und seine User per Anwaltsbrief disziplinieren.

Bambu Lab is abusing the open source social contract

---

Schmunzelecke

Einmal US Präsident spielen? Kannst du machen im Browsergame „Operation Epic Furious“ 😉

---

💡 Link Tipps aus der Open Source Welt

Gravitee API Management – Open Source API Gateway und Management

Gravitee APIM ist eine Open-Source-Plattform für API Management und Gateway – von der Registrierung über Policy-Enforcement bis zum Developer Portal und Analytics Dashboard. Flexibel, leichtgewichtig und für den kompletten API Lifecycle gebaut.

Key Features:

• API Gateway: Leistungsfähiger Gateway auf Vert.x-Basis für Traffic Management, Routing und Security
• 50+ Policies: Rate Limits, Quotas, Transformationen, Security Policies – per Flow-Editor konfigurierbar, kein Code nötig
• Developer Portal: Anpassbares Portal mit Volltextsuche, API-Dokumentation und Application Registration für API-Konsumenten
• Analytics Dashboard: 360-Grad-Sicht auf API-Nutzung out of the box, plus Export zu Grafana oder Kibana
• Plans & Security: API-Pläne mit Rate Limits, Quotas und Security Policies definieren – OAuth2, JWT, API Keys
• Dynamic Client Registration: Verknüpfung von API Management und Access Management
• Lifecycle Management: APIs erstellen, versionieren, publizieren, deprecaten – alles über Console UI oder API

Deployment: Docker Compose, Helm Charts für Kubernetes (AKS, GKS, EKS, OpenShift) oder Gravitee Cloud (SaaS). Backend benötigt MongoDB. Quick Start per make mongodb in unter 5 Minuten.

Tech Stack: Java/Vert.x (66%) Backend, TypeScript (28%) Frontend. Enterprise-Features separat lizenziert.

Gravitee positioniert sich als leichtgewichtigere Open-Source-Alternative zu Kong oder Apigee. Der Flow-basierte Policy-Editor und das integrierte Developer Portal machen es besonders für Teams attraktiv, die API Management ohne die Komplexität von Kong Enterprise oder die Vendor-Abhängigkeit von Cloud-Lösungen wollen. Mit 808 Tags/Releases und 127 Contributors ein reifes Projekt – die vergleichsweise niedrige Star-Zahl spiegelt vermutlich eher die Enterprise-Nische als mangelnde Qualität wider.

https://github.com/gravitee-io/gravitee-api-management

Needle – 26M Parameter Function-Calling Modell für Tiny Devices

Needle ist ein winziges (26 Millionen Parameter) KI-Modell, das speziell für Single-Shot Function Calling optimiert wurde – destilliert aus Gemini 3.1, lokal auf Mac/PC finetunebar und designed für Consumer Devices wie Phones, Watches oder Glasses.

Key Features:

• Winzig und schnell: 26M Parameter „Simple Attention Network“ (d=512, 8 Attention Heads, BPE=8192). Auf Cactus-Infrastruktur 6000 tok/s Prefill, 1200 tok/s Decode
• Function Calling fokussiert: Spezialisiert auf Tool-Aufrufe – schlägt FunctionGemma-270m, Qwen-0.6B, Granite-350m und LFM2.5-350m bei Single-Shot Function Calls
• Einfaches Finetuning: needle playground startet eine Web UI zum Testen und Finetunen auf eigene Tools. Trainingsdaten können per Gemini automatisch generiert werden – ab 120 Beispielen pro Tool
• Encoder-Decoder Architektur: Encoder für den Query-Text, Decoder mit Cross Attention für die Tool-Call-Generierung, Gated Residuals, RoPE, GQA
• Open Weights: Modell und Dataset-Generierung komplett offen

Training: Pretrained auf 16 TPU v6e mit 200B Tokens (27 Stunden), Post-Training auf 2B Tokens Function-Call-Daten (45 Minuten).

Ein spannender Ansatz für die Frage „wie klein kann ein Modell sein und trotzdem zuverlässig Tools aufrufen?“ – relevant für Edge-AI-Szenarien, wo ein vollwertiges LLM nicht läuft. Das Finetuning auf eigene Tools mit Web UI und automatischer Datengenerierung senkt die Einstiegshürde enorm. Wichtig: Needle ist kein Allzweck-LLM, sondern ein Spezialist für Function Calling – für Conversations und generelle Aufgaben sind größere Modelle nach wie vor besser.

https://github.com/cactus-compute/needle

❓ Feedback & Newsletter Abo

Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.

Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: