Willkommen zu allesnurgecloud.com – Ausgabe #233
Dienstag und Mittwoch war ich auf der Rack & Stack Konferenz von Golem in Nürnberg. Die Konferenz hatte zum Thema „souveräne IT-Infrastrukturen“ einiges zu bieten. Besonders gefallen haben mir 2 hands-on-Vorträge – einmal von Benedikt Heine von der Video Plattform 3Q zum Thema „Co-Location, wie geht das nochmal?“ (Talk bei GitHub) und von Sebastian Kurfürst von der Agentur sandstorm zum Thema „Self Hosted Kubernetes ohne Dev-Ops Team“ (Blog Artikel).
Eugen und ich durften etwas aus der Praxis zu „Mut zum Cloud Exit“ am Beispiel von Everysize erzählen. Hat uns Spaß gemacht und das Feedback war super – wir kommen gerne wieder. Die Artikel werde ich nächste Woche im NL etwas vorstellen, hat mir die Woche nicht mehr gereicht.
Dazu passt ein ernüchternder Realitätscheck: Der Bund gibt jährlich 8 Milliarden Euro für IT aus, die 180-Millionen-EU-Ausschreibung ist dagegen eine Randnotiz. 470.000 Windows-Arbeitsplätze stehen 12.900 alternativen Desktops gegenüber, von denen genau 70 auf openDesk laufen. Frankreich hat im öffentlichen Sektor deutlich konsequenter umgesteuert – hierzulande bleibt digitale Souveränität Folienware (Artikel dazu in der SZ).
Wer ansonsten in den letzten Tagen mit der Qualität von Claude Code unzufrieden war, kann mal das Postmortem hier bei Anthropic durchlesen – es sollte nun wieder besser sein.
Ach und jemand hat mir das Buch „Kein Horn“ von meiner Amazon Wunschliste geschickt – Danke! Leider war keine Nachricht dabei, damit weiß ich nicht, wo ich mich bedanken kann – So, und nun viel Spaß mit Ausgabe #233.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 169 habe ich mit Florian Feilmeier gesprochen. Florian baut mit TRADElube eine Integrationsplattform und ein PIM-System, das Warenwirtschaftssysteme mit Shopware, WooCommerce und Shopify verbindet – hauptsächlich für Fahrradhändler. Heute hat er rund 60 Kunden und 4.700 Euro MRR, obwohl er die letzten fünf Jahre praktisch kein Marketing gemacht hat. Die Warenwirtschaftshersteller empfehlen ihn einfach direkt weiter, ohne Kooperationsvertrag. Das Ganze parallel zu einem 12-Stunden-Job als Senior Softwareentwickler. 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:
Vercel Security Incident: OAuth-Kette via Context.ai
Vercel, Betreiber der gleichnamigen Deployment-Plattform und Entwickler von Next.js, hat am 19. April einen Security Incident offengelegt, der inzwischen als einer der lehrreichsten Supply-Chain-Fälle des Jahres 2026 gilt. Die exzellente Analyse stammt von Peter Girnus bei Trend Micro – wer sich für OAuth-Supply-Chain-Angriffe interessiert, findet dort eine vollständige MITRE-ATT&CK-Zuordnung.
Die Angriffskette illustriert das Problem moderner SaaS-Verflechtungen:
- Februar 2026 – Lumma-Stealer-Infektion bei Context.ai, einem kleinen AI-Analytics-Anbieter
- März 2026 – Angreifer exfiltrieren Google-Workspace-OAuth-Tokens aus der Context.ai-AWS-Umgebung
- März/April – Pivot in das Workspace-Konto eines Vercel-Mitarbeiters, dann in Vercels interne Systeme
- April 10 – OpenAI benachrichtigt einen Vercel-Kunden über einen „in the wild“ gesichteten API-Key – neun Tage vor der offiziellen Disclosure
- April 19 – Vercel informiert betroffene Kunden
Das eigentlich Brisante liegt im Design: Environment Variables bei Vercel waren standardmäßig nicht als sensitive markiert und lagen damit unverschlüsselt „at rest“. Jeder DATABASE_URL oder STRIPE_SECRET_KEY, den Entwickler nicht explizit als sensitive flaggten, war lesbar. Vercel hat inzwischen das UI verbessert – den Default hat man aber noch nicht gedreht. CEO Guillermo Rauch attribuiert die „ungewöhnliche Geschwindigkeit“ der Angreifer übrigens AI-Unterstützung, was die BleepingComputer-Berichterstattung zusätzlich unterfüttert – ShinyHunters-Affiliate fordert angeblich 2 Millionen Dollar Lösegeld.
Die Attribution bleibt dabei trüb. vx-underground hat auf X nüchtern aufgedröselt, dass ein Account namens „ShinyHunters“ auf BreachForums.ai den Post absetzte – während die echte ShinyHunters-Gruppe via Telegram bestreitet, hinter dem Angriff zu stecken. Zwischenzeitlich existierten acht verschiedene Iterationen von BreachForums beziehungsweise RaidForums nach diversen Takedowns. Auf Hacker News warnt Theo Browne: „Everything I know about this hack suggests it could happen to any host.“ Der Fall reiht sich ein in LiteLLM und Axios aus Ausgabe 195.
Ich hoffe, du warst von dem Incident nicht betroffen, von dem ein oder anderen Vercel User und Mitarbeitenden weiß ich – daher HugOps und ich hoffe, ihr habt es mittlerweile überstanden.
Wero auf AWS: Europäischer Bezahldienst, US-Infrastruktur
Daniel Leisegang hat auf netzpolitik.org einen bemerkenswert unangenehmen Widerspruch aufgedeckt: Der europäische Bezahldienst Wero, getragen von der European Payments Initiative (EPI) mit Deutscher Bank, Postbank, ING, Sparkassen und Volksbanken, wirbt plakativ als „DIE starke und unabhängige europäische Lösung beim digitalen Bezahlen“ – läuft aber teilweise auf Amazon Web Services. Das passt ungefähr so zusammen wie Cola-Light beim Marathon.
Auf Anfrage musste EPI einräumen, dass man „Managed-Infrastructure- und Software-Services von AWS“ nutzt, wolle aber „die volle Kontrolle über Architektur, Sicherheitsmodell und Betrieb“ behalten. Die bekannten Souveränitäts-Floskeln: Verschlüsselung „in transit“ und „at rest“, strenge Zugriffskontrollen, Audit-Protokolle. Das eigentliche Problem ignoriert man damit elegant: der US CLOUD Act von 2018 verpflichtet US-Tech-Anbieter auch bei Daten außerhalb der USA zur Herausgabe an US-Behörden. Ein vom Bundesinnenministerium beauftragtes Gutachten der Universität Köln vom März 2025 attestiert der Nutzung von US-Clouddiensten ein „erhebliches Risiko des Datenabflusses“. EPI selbst sieht „potenzielle extraterritoriale Zugriffsanfragen als relevantes rechtliches und geopolitisches Risiko“ – und verweist auf bestehende Notfall- und Ausstiegspläne. Beruhigend.
AWS hatte passend dazu Ende 2025 die European Sovereign Cloud in Brandenburg gestartet – 7,8 Milliarden Euro Investition, nur EU-Personal, separate Governance-Struktur. Doch auch hier bleibt das Kernproblem: Die Muttergesellschaft unterliegt weiterhin US-Recht, wie ich bereits bei der Microsoft-Sovereign-Cloud-Diskussion in Ausgabe 193 herausgearbeitet hatte. Benjamin Schilz von Wire brachte es damals auf den Punkt: „Es gibt keine rechtliche Hürde, die die US-Regierung daran hindern würde, von Microsoft den Einbau von Hintertüren zu verlangen.“
Bezeichnend ist die Signalwirkung: Wenn schon ein Zusammenschluss europäischer Großbanken, der mit finanzieller Souveränität wirbt, keine rein europäische Infrastruktur aufbaut, wird es auch niemand anders tun. Parallel dazu gab es diese Woche den 180-Millionen-Euro-Cloud-Deal der EU-Kommission – immerhin ein Anfang, aber angesichts des Wero-Falls eher Symbolpolitik denn Marktkorrektur.
Europäischer Bezahldienst Wero nutzt Amazon-Server
Anzeige
Cloud Exit mit „We Manage“ – 80 % Kosten gespart bei Everysize.com
Als everysize mit seiner Cloud-Infrastruktur an Grenzen stieß, fand das Unternehmen in We Manage den idealen Partner.
Das Ergebnis: 80% Kostenreduktion bei gleichzeitiger Leistungssteigerung.
„Der Profi-Sysadmin, den ich inhouse bräuchte, der aber bei mir zu wenig zu tun hätte,“ beschreibt Mitgründer Eugen Falkenstein treffend die Rolle von We Manage für sein Unternehmen.
Durch maßgeschneiderte IT-Operations, 24/7-Monitoring und Cloud-Migration befreite sich everysize vom teuren AWS-Vendor-Lock-in. Die Serverkosten sanken von 50.000 auf nur 10.000 Euro jährlich – bei höherer Zuverlässigkeit und Agilität.
Brauchst du Hilfe bei Cloud-Optimierung oder IT-Operations?
Lies die vollständige Case Study und erfahre, wie auch dein Unternehmen von We Manage profitieren kann – buch dir jetzt einen Termin zum Kennenlernen.
zur Case Study: Warum everysize die AWS Public Cloud hinter sich lässt
Meeting ohne Agenda? Einfach absagen
Ben Balter, Director of Hubber Enablement bei GitHub und langjähriger Verfechter asynchroner Arbeit, hat mit noagendanomeeting.net eine Single-Page-Site gelauncht, die eine simple These vertritt: Jedes Meeting verdient eine Agenda – und die meisten Meetings verdienen es, stattdessen ein Dokument zu sein. Im begleitenden Blog-Artikel formuliert er pointiert, was viele kennen: Man bekommt einen Kalendereintrag mit Titel „Quick sync“, 30 Minuten blockiert, keine Beschreibung, kein Dokument – und nimmt trotzdem teil, weil man dem Skip-Level-Manager schwer absagen kann.
Seine Analogie aus der Entwicklerwelt sitzt: Ein Meeting ohne Agenda ist wie eine Funktion ohne Dokumentation – sie tut vielleicht, was man erwartet, zwingt aber jeden Aufrufer, die Implementierung zu lesen, um das herauszufinden. Der durchschnittliche Wissensarbeiter verbringt laut Balter bereits 40 Prozent seiner Arbeitswoche in Meetings. Ohne klare Ziele driften diese ab, Entscheidungen werden nicht getroffen, und am Ende fragen sich alle, ob das nicht auch eine E-Mail hätte sein können.
Balters Kernargument: Schreiben skaliert, Meetings tun das nicht. Vor jedem Invite sollte die Frage stehen, ob der Vorgang nicht als Dokument beginnen kann. Falls es doch ein Meeting werden muss, gehören Agenda, Read-Ahead und die zu treffende Entscheidung in die Einladung. Sein pragmatischer Vorschlag: Beim nächsten agendafreien Invite einfach absagen – oder diplomatischer um eine Agenda bitten und den Link zu noagendanomeeting.net mitschicken.
Passend dazu Shopifys Radikalkur aus Ausgabe 88, bei der 76.500 Stunden Meeting-Zeit gestrichen wurden – wobei Becky vom Twist-Blog zu Recht anmerkte, dass asynchrones Arbeiten mehr erfordert als nur das Streichen von Terminen. Ergänzend der Fahrplan von Marissa Goldberg aus Ausgabe 164, wenn man gegen die eigene Meeting-Flut ankommen möchte.
High-Quality Chaos: 50 CVEs für cURL
Daniel Stenberg, Maintainer des cURL-Projekts, hat in seinem Blog unter dem Titel High-Quality Chaos eine erstaunliche Kehrtwende dokumentiert. Nachdem das Projekt sein Bug-Bounty-Programm wegen KI-Slop im Februar dieses Jahres komplett abgeschaltet hatte, lief der Neustart im März über Hackerone – mit überraschenden Ergebnissen.
Die Zahlen seit März 2026:
- Report-Frequenz doppelt so hoch wie 2025, das seinerseits doppelt so hoch wie davor lag
- Rate bestätigter Vulnerabilities zurück auf 15–16 Prozent wie vor der KI-Welle
- Zusätzlich deutlich mehr Reports, die echte Bugs (wenn auch keine Security-Issues) finden
- Prognose: bis zu 50 veröffentlichte CVEs im cURL-Projekt 2026
Praktisch alle Reports nutzen mittlerweile KI – erkennbar an Wortwahl, Struktur und bemerkenswert detaillierten Duplikaten. Stenberg bestätigt auf Mastodon, dass der Trend projektübergreifend gilt: Apache httpd, BIND, Django, Firefox, git, glibc, Linux Kernel, Python, Wireshark und viele mehr sehen dasselbe.
Die Kehrseite der Medaille: Diese Tools stehen auch den Angreifern zur Verfügung. Stenberg warnt, dass die kommende CVE-Lawine Maintainer überlasten wird, bevor Anwender Zeit zum Patchen finden. Mozilla kommt in eigenen Tests mit Mythos zu optimistischerem Fazit – man finde keine grundsätzlich neuen Angriffsklassen, nur bekannte schneller.
Zero Day Clock: TTE kollabiert auf Minuten
Sergej Epp, CISO bei Sysdig, hat mit der Zero Day Clock ein Dashboard gebaut, das den Kollaps der Time-to-Exploit-Fenster in Echtzeit visualisiert – und die Zahlen sind tatsächlich beängstigend. Datenbasis sind 3.531 CVE-Exploit-Pärchen aus der CISA KEV, der VulnCheck KEV und VulnCheck XDB, ergänzt um ExploitDB, Metasploit, Nuclei und andere Quellen. Die VulnCheck KEV gilt dabei als aggressiver kuratiert als die CISA-Liste und nimmt Exploits im Schnitt 28 Tage früher auf.
Die Milestones der Time-to-Exploit-Kompression:
- 2018 – Median bei 771 Tagen, über zwei Jahre Zeit zum Patchen
- 2021 – 1-Jahres-Schwelle unterschritten
- 2023 – nur noch 6 Tage bis zum ersten Exploit
- 2024 – 4 Stunden, AI verändert die Kalkulation grundlegend
- 2026 – 1-Tages- und 1-Wochen-Schwelle gerissen, 72,7 Prozent aller exploiteten CVEs sind Zero Days
- 2028 – Projektion: 1 Minute
Die Mean TTE für 2026 liegt aktuell bei 10 Stunden, der Median sogar bei minus 18 Stunden – die Mehrheit der Exploits ist bereits aktiv, bevor die CVE überhaupt veröffentlicht wird. Im Resilient-Cyber-Newsletter wird Daniel Kangs Forschung zitiert, wonach GPT-4 bekannte Software-Lücken autonom mit 87 Prozent Erfolgsrate zu 8,80 Dollar pro Exploit durchspielen kann. Parallel brauchen Organisationen laut CISA-Daten nach wie vor 55 Tage, um 50 Prozent der Schwachstellen zu remedieren. Die Rechnung geht nicht mehr auf.
Passend dazu Daniel Stenbergs cURL-Befund aus dem vorherigen Artikel: Bis zu 50 CVEs allein für cURL in 2026, weil AI nun Lücken in Serie findet. Die unangenehme Konsequenz: Wenn die Reaktionszeit 2028 bei einer Minute liegt, ist manuelles Patchen endgültig obsolet. Dann müssen AI-Agenten gegen AI-Agenten antreten – vollautomatische Detection, automatischer Patch-Build, automatisches Deployment in die Produktion. Security wird vom Mensch-zu-Mensch-Wettrüsten zum Agent-zu-Agent-Krieg. Ob unsere Deployment-Pipelines dafür bereit sind, ist eine ganz andere Frage. Und ob wir uns dadurch nicht dann wieder neue Probleme einfangen, auch.
Zero Day Clock: From Vulnerability to Exploitation
Reliability vs Security: GitHubs Dilemma
Lorin Hochstein, Resilience-Engineering-Experte und ehemaliger Netflix-SRE, hat auf seinem Blog Surfing Complexity die jüngsten GitHub-Ausfälle analysiert. Anlass war der Beitrag von Vlad Fedorov, CTO bei GitHub, der drei Incidents öffentlich aufgearbeitet hat: einen überlasteten Datenbank-Cluster, eine Security-Policy, die den Zugriff auf VM-Metadaten blockierte, und einen Redis-Cluster-Ausfall. Dass GitHub hier detailliert kommuniziert, lobt Hochstein – die meisten Anbieter bleiben bei „upstream provider issues“ stehen.
Spannend ist die Anatomie des Datenbank-Incidents, ausgelöst durch mehrere unabhängige Faktoren:
- Release eines neuen AI-Modells am Samstag bei niedriger Last
- Reduktion der User-Settings-Cache-TTL von 12 auf 2 Stunden
- Regulärer Montags-Peak
- Parallele Client-App-Updates mit erhöhter Read-Last
Das klassische Muster der „Brittle Collapse“: Die Gefahr wuchs unsichtbar, weil die Last nur beim seltenen Model-Rollout sichtbar wurde und zwischen den Rollouts durch den TTL-Cache maskiert war. Hochsteins zentrale Einsicht: Failover-Mechanismen erzeugen Alternativ-Modi, in denen neuartige Fehler auftauchen – genau so geschehen bei den Februar- und März-Incidents. Automatisierung allein reicht nicht, Responder brauchen granulare manuelle Kontrollmöglichkeiten.
Wie dramatisch die Lage ist, zeigt The Missing GitHub Status Page aus Ausgabe 223. Die Macher formulieren spitz: „GitHub stopped updating its status page with aggregate uptime numbers some time ago — if you use it regularly, you might have a feeling why.“ Die rekonstruierten Zahlen: 91,95 Prozent Uptime in 90 Tagen bei 72 Incidents, Februar mit nur 83,13 Prozent. Selbst Git Operations liegt nur bei 99,57 Prozent. Bereits in Ausgabe 105 (lange her) hatte ich eine ähnliche Ausfallserie aufgegriffen – manche Muster wiederholen sich offenbar hartnäckig.
Quick thoughts on GitHub CTO’s post on availability
Qwen3.6-27B und Kimi K2.6: Open Source holt auf
Zwei chinesische Open-Source-Labore haben in dieser Woche Coding-Modelle veröffentlicht, die den üblichen „Open Source ist eh hinterher“-Reflex zumindest erschüttern dürften. Qwen3.6-27B von Alibabas Qwen-Team und Kimi K2.6 von Moonshot AI zielen beide explizit auf Agentic Coding – und liefern Benchmark-Zahlen, die Claude Opus 4.6 und GPT-5.4 ernsthaft in Bedrängnis bringen. Die Hardware-Anforderungen könnten aber kaum unterschiedlicher sein.
Qwen3.6-27B ist die bemerkenswertere Architekturentscheidung: 27 Milliarden Parameter in dense Architektur, kein MoE-Routing, dafür einfacheres Deployment. Das Modell schlägt den eigenen MoE-Vorgänger Qwen3.5-397B-A17B in jedem Coding-Benchmark – bei 15-facher Parameter-Reduktion. Die Kennzahlen:
- SWE-Bench Verified 77,2 (vs. 76,2 beim 397B-Vorgänger)
- SWE-Bench Pro 53,5 (vs. 50,9)
- Terminal-Bench 2.0 59,3 – Gleichstand mit Claude Opus 4.6
- GPQA Diamond 87,8 bei reinen Reasoning-Tasks
- Multimodal (Text und Bild) im selben Checkpoint
Für lokales Deployment braucht Qwen3.6-27B realistisch 48-54 GB VRAM bei FP16 – eine einzelne RTX 6000 Ada oder zwei RTX 4090 reichen. Mit 4-Bit-Quantisierung landet man bei 16-18 GB VRAM, was auf einer RTX 4090 oder sogar einer 3090 läuft. Open Weights gibt es auf HuggingFace und ModelScope.
Kimi K2.6 von Moonshot AI spielt in einer anderen Liga – im wörtlichen Sinn. Mit 1 Billion Gesamtparametern und 32 Milliarden aktiven Parametern per MoE-Routing braucht das Modell für Full Precision 2 TB VRAM, mit 8-Bit-Quantisierung 1 TB (also 8x H200 oder 6x B200). Selbst Unsloths 2-Bit-Quant kommt noch auf 375 GB – das ist kein Consumer-Setup, sondern ein Rechenzentrum. Dafür liefert Kimi K2.6 bei Long-Horizon-Coding beeindruckende Ergebnisse: autonome Optimierung einer acht Jahre alten Trading-Matching-Engine über 13 Stunden mit 1.000 Tool-Calls und 133 Prozent Throughput-Zuwachs. SWE-Bench Pro liegt bei 58,6 – vor Claude Opus 4.6 und GPT-5.4. Vercel meldet über 50 Prozent Verbesserung auf dem Next.js-Benchmark.
Beide Modelle sind via Anthropic-API-Protokoll nutzbar – wer Claude Code bereits konfiguriert hat, kann sein ANTHROPIC_BASE_URL einfach umbiegen. Für Self-Hosting ist Qwen3.6-27B die praktikable Wahl, Kimi K2.6 läuft für die meisten nur via API.
Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
Grafana 13: Loki 10x schneller, KI braucht Cloud
Grafana Labs hat auf der GrafanaCON 2026 in Barcelona Version 13 der Open-Source-Observability-Plattform vorgestellt. Matthias Parbel hat das Release bei heise developer gut eingeordnet, die offizielle Ankündigung liefert die technischen Details. Das wichtigste Detail vorweg: Grafanas eigener KI-Assistent ist ab sofort auch für OSS- und Enterprise-Selfhoster verfügbar – allerdings nur über einen verknüpften Grafana-Cloud-Account. Echte „Local-AI-Observability“ sieht anders aus.
Die nennenswerten Neuerungen aus dem Release:
- Loki 3.5 scannt laut Grafana bis zu 20-mal weniger Daten bei Aggregationsabfragen und antwortet 10-mal schneller – neuer Query Planner mit Data Locality plus Kafka-Ingestion
- Übernahme von Logline für bessere Volltextsuche bei Logs mit hoher Kardinalität, was VictoriaMetrics‘ Kritik aus Ausgabe 180 adressiert
- Dynamic Dashboards mit neuem Schema v2 und Drag-and-Drop sind GA
- Git Sync ermöglicht bidirektionale Synchronisation mit GitHub, GitLab und Bitbucket
- Suggested Dashboards schlagen Templates für DORA- oder USE/RED-Metriken vor
- Vereinfachtes OpenTelemetry-Setup mit einem Install-Kommando für Linux
Wichtige Warnung für Early-Adopter: Ein Migrations-Bug in 13.0.0 kann beim Upgrade von v12 mit aktiviertem Git Sync Dashboards und Ordner zurücksetzen. Wer upgradet, sollte zuerst auf 13.0.1 warten oder die Datenbank sichern. Das /api-Pfad wird deprecated zugunsten von /apis, und der Grafana Image Renderer ist komplett entfernt – wer Reports oder Screenshots automatisiert erzeugt, muss migrieren.
Die Loki-Optimierungen sind ein klares Zeichen, dass Grafana die Kritik aus der Community ernst nimmt – insbesondere die wiederholten Performance-Beschwerden bei Logs mit vielen einzigartigen Attributen. Ob das reicht, um VictoriaLogs und ClickHouse/ClickStack den Wind aus den Segeln zu nehmen, wird sich zeigen.
Grafana 13: Schnellere Dashboards, schlankere Logs, OpenTelemetry-Pakete
SeaweedFS 4.21 mit NFS-Server und POSIX-Compliance
Chris Lu hat am Samstag SeaweedFS 4.21 veröffentlicht – und das Release hat es in sich. Das in Go geschriebene, verteilte Dateisystem, das ich bereits in Ausgabe 134 als interessante MinIO-Alternative vorgestellt hatte, bekommt einige spannende Neuerungen, allen voran einen eingebauten NFS-Server.
Der FUSE-Mount ist laut Chris Lu nun 100 Prozent POSIX-konform – validiert über die pjdfstest-Testsuite, die auch Linux-Dateisysteme gegen POSIX-Semantik prüft (Hard-Links, Sticky-Bits, Umask-Handling, flock-Semantik und diverse andere Fallstricke). Bisher scheiterten verteilte Filesysteme oft an Edge-Cases wie gleichzeitigen Flock-Holdern oder Mkdir-Umask-Bugs – genau solche Fälle wurden in 4.21 abgeräumt. Zusätzlich eingeführt wurde Peer-to-Peer Chunk Sharing: Mount-Clients registrieren sich untereinander, und Chunks werden direkt zwischen Peers statt nur vom Volume Server geholt. Das reduziert die Last auf den Volume Servern und beschleunigt parallelen Zugriff – besonders relevant für den explizit genannten AI-Use-Case, bei dem große LLM-Model-Dateien von mehreren Nodes gleichzeitig geladen werden müssen.
Der neue NFS-Server macht SeaweedFS damit über vier Protokolle erreichbar: S3, FUSE, WebDAV und jetzt NFS. Technisch setzt das Projekt auf eine eigene NFS-Implementierung, die direkt gegen den Filer spricht – keine NFS-Gateway-Brücke, kein klassisches Kernel-NFS. Das bedeutet eine unkompliziertere Integration für Legacy-Anwendungen, die partout nur NFS sprechen, und eine weitere Option in heterogenen Umgebungen. Die S3-API wurde beim Lesen großer Dateien spürbar beschleunigt, GET-Requests laufen nun über einen per-Request ReaderCache.
Bei We-Manage haben wir unser internes Backup-System kürzlich von MinIO auf SeaweedFS migriert. Sieht bisher auch super aus: bessere Skalierung bei vielen kleinen Dateien, geringerer RAM-Overhead und eine deutlich klarere Lizenz-Situation nach dem MinIO-Community-Fallout. Bisher läuft das Setup stabil.
Schmunzelecke
„Wer braucht schon teure KI-Abos, wenn er einfach den Kundenservice von MccDonald’s anschreiben kann?“ – Tja, doof, wenn man hier dem Bot nicht beibgringt, dass er nicht coden darf… gefunden bei LinkedIn via Toby (thx)
Bei Programmerhumor drüben auf Insta gibt es einen alten Sudo Joke und mehr.
💡 Link Tipps aus der Open Source Welt
Headlamp – Kubernetes Web UI unter dem Dach der Kubernetes SIG UI
Headlamp ist ein erweiterbares, herstellerunabhängiges und schickes Kubernetes Web Dashboard, das kürzlich offiziell unter die Kubernetes SIG UI (kubernetes-sigs Organisation) aufgenommen wurde. Es kombiniert die klassische Dashboard-Funktionalität mit einem Plugin-System für individuelle Erweiterungen.
Key Features:
- Vendor-unabhängig: Funktioniert mit jedem Kubernetes-Cluster, Multi-Cluster-Support out of the box
- Flexibler Betrieb: In-Cluster Deployment oder als Desktop-App für Linux, macOS und Windows
- RBAC-aware: UI-Elemente spiegeln die tatsächlichen Berechtigungen des Users wider – kein Delete-Button ohne Delete-Permission
- Plugin-System: Erweiterbar über eigene Plugins, offizieller Plugin-Katalog auf Artifact Hub
- Editor & Tools: Logs, Exec, Resource Editor mit eingebetteter Dokumentation, abbrechbare Create/Update/Delete-Operationen
Im Vergleich zum offiziellen Kubernetes Dashboard bietet Headlamp ein moderneres UI, Plugin-Architektur und Multi-Cluster-Fähigkeit. Dass es jetzt unter kubernetes-sigs läuft, gibt dem Projekt institutionelles Gewicht.Tech Stack: TypeScript (78%) + Go (15%). Deployment via Helm Chart, Docker oder als Desktop-App. Ursprünglich von Kinvolk (Microsoft) gestartet.
Für Teams, die ein modernes Kubernetes Dashboard suchen (siehe Demo auf der Landingpage), das über die Basics hinausgeht, ist Headlamp die beste Open-Source-Option. Das Plugin-System macht es besonders attraktiv für Organisationen, die das Dashboard an eigene Workflows anpassen wollen. Mit der Aufnahme in kubernetes-sigs ist die Langlebigkeit des Projekts praktisch gesichert.
https://github.com/kubernetes-sigs/headlamp
smolvm – Portable MicroVMs mit Sub-Second Cold Start
smolvm ist ein CLI-Tool zum Erstellen und Ausführen von leichtgewichtigen Linux-VMs mit echter Hardware-Isolation – unter 200ms Boot-Zeit, elastischem Speicher und der Möglichkeit, eine komplette VM in eine einzelne portable Datei (.smolmachine) zu packen.
Key Features:
- Echte VM-Isolation: Jeder Workload bekommt einen eigenen Kernel auf Hypervisor.framework (macOS) oder KVM (Linux) – kein Shared Kernel wie bei Containern
- Sub-Second Boot: Unter 200ms Cold Start dank libkrun VMM mit Custom Kernel
- OCI-Images: Docker Hub, ghcr.io oder andere OCI-Registries direkt als MicroVM booten – kein Docker Daemon nötig
- Portable Artifacts:
smolvm pack createpackt einen Workload inklusive aller Dependencies in ein einzelnes Binary - Network Security by Default: Netzwerk ist standardmäßig aus, Allow-List für Hosts konfigurierbar – ideal für Sandboxing von untrusted Code
- SSH Agent Forwarding: Host-SSH-Keys im Guest nutzen, ohne dass Private Keys in die VM gelangen
- Smolfile: Deklarative VM-Konfiguration in TOML – Image, Netzwerk, Volumes, Auth in einer Datei
- Elastischer Speicher: Virtio Balloon – Host committed nur was der Guest tatsächlich nutzt, reclaimt automatisch
Cross-Platform: macOS (Apple Silicon + Intel) und Linux (x86_64 + aarch64). Geschrieben in Rust (83%). Verfügbar via Install-Script oder GitHub Releases.
smolvm füllt die Lücke zwischen Containern (schnell, aber Shared Kernel) und klassischen VMs (isoliert, aber langsam). Besonders spannend für AI-Agent-Sandboxing und portable Dev-Environments: Netzwerk ist default-off, SSH-Keys bleiben außerhalb der VM, und das Ganze bootet in unter 200ms. Die Pack-Funktion – eine komplette VM als einzelnes Binary – ist ein Killer-Feature für reproduzierbare Deployments. GPU-Support ist in Arbeit.
https://github.com/smol-machines/smolvm
❓ 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: