Willkommen zu allesnurgecloud.com – Ausgabe #209
Neben dem alles bestimmenden AWS Ausfall vom Montag habe ich auch einen spannenden Blick auf Remote Work.
Hierzu hab ich auch einen Film Tipp – „House of Dynamite“ erzählt auf Netflix von einem Angriff auf die USA mit einem nuklearen Gefechtskopf.
Was das mit Remote zu tun hast? Du wirst es beim schauen merken – es gibt auch hier die gleichen Challenges, die wir kennen: Unklare Verantwortlichkeiten, schlechte Verbindungen, Kamera aus, man bekommt Themen nicht mit, stimmt aber zu (oder nicht) oder quasselt dazwischen, wird ihn ungünstigen Situationen in ein ad-hoc meeting gezogen, unvorbereitet.
Ich fand die Parallelen sehr interessant, wenn das aber auch nicht das Haupt-Thema des Films ist – schaut es euch an – die Ereignisse werden aus 3 Perspektiven erzählt und das macht es recht spannend. (Deutscher Trailer).
Ansonsten war ich diese Woche auf der Startup Konferenz Heilbronn Slush’d in Heilbronn und bin noch immer etwas geflashed von dem Event. Ich durfte einen kleinen Teil beisteuern und einen „Live Podcast“ aus einem Audi E-Tron Prototypen aufnehmen, den die Hörer:innen per Kopfhörer hören konnten. Leider draußen, Wetter ziemlich schlecht und naja, wird im nächsten Jahr bestimmt besser! Hier findest du ein paar Eindrücke auf LinkedIn.
Happy Bootstrapping Podcast
Machen wir weiter mit schöneren Themen – bewerte doch bitte meinen Podcast bei Spotify oder Apple – das würde mir sehr helfen – Danke!
In der aktuellen Folge 144 spreche ich mit Johannes Kettmann vom mechanischen Walking Pad „Office Walker“. Johannes hat schon 3 Pads mit Motor „verbraucht“ und wollte mal etwas neues machen. Sein „Office Walker“ kannst du seit Donnerstag auf Kickstarter kaufen – Auslieferung ist dann im Juli 2026. Das Funding ist mit über 400.000 € schon sicher – im Podcast sprechen wir über Entwicklung, Design und sein Marketing Game vor dem Launch – hör gerne mal in Folge 144 rein (Spotify / Apple).
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen.
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:
AWS Outage: Smart-Betten, lokale Services und das Ende institutionellen Wissens
Am Montag, 20. Oktober 2025, um 3 Uhr morgens ET begann ein AWS-Ausfall in der Region US-EAST-1, der nicht nur Snapchat, Roblox und Fortnite lahmlegte – sondern auch zeigte, wie absurd abhängig wir von der Cloud geworden sind. Über den eigentlichen Ausfall wurde an vielen Stellen schon ausführlich berichtet, das spar ich mir daher erstmal. Doch die wirklich bizarren Folgen zeigen, wie tief Cloud-Infrastruktur mittlerweile in unserem Alltag verankert ist.
Smart-Betten gingen rogue: Besitzer der $2.000+ teuren Eight Sleep Pod3 Matratzenauflage entdeckten, dass ihre „smarten“ Schlaf-Heiligtümer keinen Offline-Modus haben. Null. Quasa berichtet: Die App fror ein, Temperaturkontrolle war tot, Sleep-Tracking funktionierte nicht mehr.
Der virale Tweet von Alex Browne: Er hatte sein Bett programmiert, sich vor dem Schlafengehen um +9°F vorzuheizen. Als AWS ausfiel, blieb das System in diesem Setting locked – ohne Cooling-Override. Browne verbrachte die Nacht „marinating in his own perspiration“ und tweetete: „Backend outage means I’m sleeping in a sauna. No offline mode yet.“ Für einen anderen User blieb das Bett in Schräglage hängen: „Would be great if my bed wasn’t stuck in an inclined position due to an AWS outage.“. Wer hat sich das ausgedacht?
Bald ist es ein Feature, dass die Matratze dann lokal funktioniert – am Besten noch mit monatlicher Subscription.
Postman – das eigentlich lokale API-Development-Tool – funktionierte nicht mehr. Die Ironie: Ein Tool, das helfen soll, APIs zu testen, braucht selbst AWS um zu funktionieren – da kann man sich schon mal Fragen, wer solch eine Abhängigkeit eingebaut hat.
Lokale Services: Banking-Apps, Gaming-Plattformen, Government Services, sogar Amazon.com selbst. Downdetector loggte über 8 Millionen Reports.
Corey Quinn analysiert die Problematik auf The Register und macht in Teilen „Amazon brain dran“ für das Thema verantwortlich. Die beunruhigende Frage: Wo sind die Senior-Engineers hin, die das schon mal erlebt haben?
Seine These: Sie haben das Gebäude verlassen – und nahmen Jahrzehnte institutionelles Wissen mit:
- 27.000+ Amazonians von Layoffs betroffen (2022-2024, continuing 2025)
- 69-81% regretted attrition laut internen Dokumenten („people quitting who we wish didn’t“)
- Return-to-Office-Initiative trieb Senior-Talente weg
- 75 Minuten brauchte AWS, um von „things are breaking“ zu „we’ve narrowed it down to DynamoDB DNS“ zu kommen
Quinn zitiert Justin Garrison, der Ende 2023 AWS verließ und „Large Scale Events“ für 2024 prophezeite. Die Prognose war nur um ein Jahr daneben.
„You can hire smart people who explain how DNS works at a deep technical level, but you can’t hire the person who remembers that when DNS starts getting wonky, check that seemingly unrelated system in the corner, because it has historically played a role.“
Quinns Warnung: „This is a tipping point moment. The talent who understood the deep failure modes is gone. The new, leaner teams lack the institutional knowledge.“ Seine Vorhersage: „The next outage is already brewing. It’s just a matter of which understaffed team trips over which edge case first.“
Dieser Ausfall ist ein interessantes Lehrstück über IoT-Absurdität und Corporate-Kurzsichtigkeit. Eight Sleep mit $110M Funding und $300M Revenue baut Betten ohne Offline-Mode. AWS mit Jahrzehnten Erfahrung braucht 75 Minuten, um ein DNS-Problem zu identifizieren, weil die Engineers, die das vielleicht schon mal gesehen haben, nicht mehr da sind.
Tribal Knowledge ist unbezahlbar. Layoffs mögen kurzfristig die Bilanz verbessern, aber wenn das nächste Mal DNS „wonky“ wird, sitzt niemand mehr im Raum, der sich erinnert, welches „unrelated system in the corner“ historisch eine Rolle gespielt hat. Und dann schlafen wir alle in AWS-gesteuerten Saunen.
Amazon brain drain finally sent AWS down the spout
AWS US-EAST-1 Ausfall: Anatomie einer fatalen Kaskade
Wie die meisten von euch wissen erlebte AWS am 19. und 20. Oktober 2025 einen massiven Ausfall in der Kern-Region us-east-1, der über 15 Stunden andauerte und in drei Phasen verlief. In einem detaillierten Post-Mortem erklärt AWS die komplexen Ursachen des Incidents.
Die drei Ausfallphasen:
- Phase 1 (23:48 – 02:40 Uhr): DynamoDB mit erhöhten API-Fehlerraten
- Phase 2 (05:30 – 14:09 Uhr): Network Load Balancer mit Verbindungsfehlern
- Phase 3 (02:25 – 13:50 Uhr): EC2 Instance Launches schlugen fehl
Root Cause: Race Condition im DNS-System
Der Auslöser war eine latente Race Condition im DNS-Management-System von DynamoDB. Die Architektur besteht aus zwei Komponenten: dem DNS Planner (monitort Kapazität und erstellt DNS-Pläne) und dem DNS Enactor (setzt Änderungen in Route53 um). Als ein Enactor ungewöhnlich verzögert arbeitete und zeitgleich ein zweiter die neuesten Pläne anwendete, überschrieb der verzögerte Enactor einen aktuellen DNS-Plan mit einem veralteten. Der Clean-up-Prozess löschte dann diesen alten Plan – und damit alle IP-Adressen des regionalen DynamoDB-Endpoints.
Kaskadeneffekt: EC2 und Network Manager
Die DynamoDB-Störung führte zu einem klassischen Cascading Failure: Der Droplet Workflow Manager (DWFM) konnte keine State-Checks mehr durchführen, Leases zwischen DWFM und Droplets liefen aus. Nach DynamoDB-Recovery geriet DWFM in einen Congestive Collapse – die Warteschlangen wuchsen schneller als sie abgearbeitet werden konnten. Erst durch selektive DWFM-Host-Restarts ab 04:14 Uhr gelang die Stabilisierung. Der Network Manager kämpfte anschließend mit einem massiven Backlog an Netzwerk-State-Propagationen, was neue EC2-Instanzen ohne Netzwerk-Connectivity ließ.
Wenn DynamoDB-DNS nicht auflöst, können Services nicht auf ihre Datenbank zugreifen. Das betrifft nicht nur direkte DynamoDB-Nutzer, sondern alle Services, die intern DynamoDB verwenden – und das sind scheinbar recht viele.
AWS hat die fehlerhafte DNS-Automation nun weltweit deaktiviert und arbeitet an mehreren Fixes: Behebung der Race Condition, Velocity Controls für NLB-Kapazitätsänderungen, erweiterte Scale-Tests für DWFM-Recovery und verbesserte Throttling-Mechanismen.
Auch die großen Cloud-Provider kochen nur mit Wasser – besonders us-east-1 bleibt eine kritisch, zentrale Region mit weitreichenden Abhängigkeiten für zentrale AWS-Services. Was ich daran nicht verstehe, ist dass immer noch so viele Kunden ihre Anwendungen primär in dieser Region deployed haben und nicht in anderen.
Zusätzlich problematisch: erst 75 Minuten nach dem eigentlichen Incident Beginn, um 02:01 Uhr, identifizierten Engineers die Root Cause: DNS-Resolution des DynamoDB API Endpoints für US-EAST-1.In diesen 75 Minuten zeigte die AWS Status Page „all is well!“. Corey Quinn merkte dazu sarkastisch an: „It’s not as if AWS had previously called out slow outage notification times as an area for improvement. Multiple times even.“
Trotzdem ist es für AWS ungewöhnlich, dass man so früh einen detaillierten Incident Report veröffentlicht. Historisch ist man dort nicht mit super transparenten PMs aufgefallen – Gergely Orosz hatte das mal analysiert und für das Jahr 2023 ein ganzes Public PM bei AWS gefunden, während Azure 15 und Google gar über 100 veröffentlicht haben.
Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region
Anzeige
Hier könnte Deine Werbung stehen
Du möchtest Deine Firma, angebotene Dienstleistungen & Services oder Dein SaaS Produkt hier im Newsletter vorstellen?
Du suchst neue Mitarbeiter und möchtest diese direkt erreichen?
Erreiche über 1400 Cloud und Open-Source Enthusiasten direkt per E-Mail und im RSS Feed. Dazu kommen 1000+ Impressions im LinkedIn Artikel des Newsletters.
Die Preise beginnen ab 150€ pro Ausgabe – bei Interesse antworte mir direkt auf den Newsletter oder kontaktiere mich über LinkedIn ich schreib dann auch ganz schnell zurück.
Jetzt Werbung anfragen (und Freitags deployen)
Remote Work unter Beschuss
Mitchell Hashimoto, Mitgründer von HashiCorp, äußert sich besorgt über die aktuelle Entwicklung bei Remote-Hiring – und seine Bedenken werden von Tech-Journalist Gergely Orosz bekräftigt. Die Kernaussage: Einige wenige Betrüger haben das Vertrauen in Remote Work massiv beschädigt.
Die Probleme, die Hashimoto und andere Founder beschreiben, gehen über klassisches „Faulenzen“ hinaus. Es geht um systematischen Betrug: Mitarbeitende mit mehreren Vollzeitjobs parallel, Interview-Proxies (jemand anderes gibt sich als Kandidat aus), oder Personen aus Ländern, in denen keine Arbeitserlaubnis vorliegt. Mitchell berichtet, dass solche Fälle bei HashiCorp in 10 Jahren etwa ein Dutzend Mal vorkamen – heute scheint es laut seinen Kontakten geradezu grassierend.
Besonders bitter: Orosz beschreibt Fälle von langjährigen, vertrauenswürdigen Mitarbeitern, die plötzlich mehrere Jobs parallel betrieben. Founder stellen sich nun die Frage: „Ist es das wert, jeden einzelnen Mitarbeiter zu kontrollieren?“ Die einfache Antwort vieler: Hybrid oder Office – das löst das Problem.
Die Konsequenzen für echte Remote-Worker
Hashimoto selbst baute ein Unternehmen mit tausenden Remote-Mitarbeitern auf – und versteht die Sorgen internationaler Talente wie Alexandre Juca aus Afrika, für den Remote Work Türen zu Chancen öffnete, die sonst unerreichbar wären.
Die Ironie: Während Dell Mitarbeiter zurück ins Büro zwingt und sich damit massiven Widerstand einhandelt, entwickelt sich Remote Work wieder zum Privileg für Bewährte – wie vor 2020. Full-Remote Unternehmen haben nun einen Vorteil: Sie können leichter Top-Talente anwerben, die bei Hybrid-Firmen keine Chance mehr bekommen.
MinIO zieht der Community den Teppich unter den Füßen weg
MinIO, der populäre S3-kompatible Object Storage Server, sorgt erneut für Kontroversen: Das Unternehmen hat ohne Vorankündigung die Bereitstellung von vorgefertigten Binaries und Docker Images für die Community Edition eingestellt, wie Bobby Borisov auf Linuxiac berichtet.
Was war passiert?
Juni 2025: MinIO entfernt nahezu alle nützlichen Tools aus der Admin-Webkonsole der Community-Version – nur zahlende Kunden behalten Zugriff (GitHub Issue).
Oktober 2025: User bemerken fehlende Docker- und Quay-Images. In einem GitHub Issue bestätigen die Maintainer: Ab sofort nur noch „Source-Only Distribution“. Die Docker Images auf Docker Hub wurden über 1 Milliarde Mal heruntergeladen – entsprechend groß ist der Impact.
Besonders pikant: Im GitHub-Thread meldet sich ein zahlender Kunde: „I’m a paying customer and this is a huge red flag for me. If MinIO is willing to break trust with their community users this way, what guarantees do I have that similar changes won’t affect enterprise customers down the line?“ Die Botschaft: Selbst zahlende Kunden verlieren das Vertrauen, wenn ein Unternehmen seine Community derart vor den Kopf stößt.
Die Community reagiert empört
Vadim Bauer, CNCF Harbor Maintainer, analysiert auf LinkedIn: „Another day, another open-source rug pull.“ MinIO hat über $100M Funding eingesammelt und versuche nun, auf der AI-Welle zu reiten. Seine Kritik: Features werden entfernt (SSO, LDAP als „unmaintained“ markiert – klassische SSO Tax), und Änderungen werden ohne Ankündigung ausgerollt.
Sein Vergleich: KubeSphere machte vor wenigen Monaten einen ähnlichen „Surprise Rug Pull“ – heute ist das Projekt tot. „No issues, no PRs, nothing.“ Bauers Fazit: „Despite a lot of evidence from Elastic, Redis, Terraform, MongoDB on how NOT to ruin a business, people repeat the same error again.“
Auf Hacker News explodierte die Diskussion mit über 500 Kommentaren. Hier die drei brisantesten:
1. Dokumentation bereits vor Wochen eingestellt: User mattbee enthüllt, dass MinIO die Dokumentation schon Wochen zuvor stillschweigend entfernte – sein 100PB Cluster kostet bei MinIO Support fast so viel wie S3 Storage selbst. *“It seems super-clear they’re stopping those contributions, and I’d bet the final open source release will happen in the next year.“*
2. Console-Removal während Upgrade: User Kevinmetaba erlebte den Schock live: „During an upgrade, I discovered that the console had been removed without any prior notice.“ Er wechselte zu RustFS, während User nunez warnt: YC-Investment bedeutet oft nur „open-source until it’s no longer fiscally prudent.“
3. Eine Woche ist keine Warnung: User malicka bringt es auf den Punkt: „That commit is from last week. One week is not at all a sufficient warning, that’s rash and makes them look quite bad. Practically manic.“
Alternativen gewinnen an Bedeutung
Bauer nennt für primäre S3-Storage-Use-Cases: SeaweedFS, RustFS, Ceph und Garage (by Deuxfleurs). Diese „new players claim to be a magnitude faster and easier to maintain than MinIO“ – ohne dessen massive Legacy.
User-Kommentare auf Linuxiac bestätigen den Trend:
- Nick: „We are looking to replace Minio with Exaba, designed specifically for multi-tenancy, all built in Rust.“
- Victor: „We are trying to replace MinIO with RustFS. This policy is too disappointing.“
MinIO zeigt hier „lehrbuchmäßig“, wie man eine loyale Open-Source-Community verprellt. Die fehlende Transparenz (Änderungen tauchen über Nacht auf, versteckt in GitHub-Threads) zeigt Respektlosigkeit gegenüber den Usern, die das Projekt groß gemacht haben. Mit über $100M Funding hätte MinIO die Ressourcen für saubere Kommunikation. Stattdessen: Nacht-und-Nebel-Aktionen, die CI/CD-Pipelines und Deployments brechen. Die genannten Alternativen sind teilweise production-ready – MinIOs Verhalten beschleunigt nur die Migration.
So, ich muss dann auch mal schauen, in welche Richtung es geht – RustFS ist noch in Development, daher wird es wohl Garage oder SeaweedFS – hast du mit einem der Tools Erfahrung?
MinIO Again Under Fire for Source-Only Decision
Meta’s Kampf gegen Fehler in KI Hardware
Meta’s Engineering Team hat in einem ausführlichen Artikel detailliert beschrieben, wie das Unternehmen mit Hardware-Fehlern in seiner massiven AI-Infrastruktur umgeht – und warum Silent Data Corruptions (SDCs) zur größten Herausforderung geworden sind.
Die drei Kategorien von Hardware-Fehlern
Meta klassifiziert Fehler in Static Errors (Gerät funktioniert oder nicht), Transient Errors (Last- oder temperaturabhängig) und Silent Errors – letztere sind besonders tückisch, da Hardware falsch rechnet, ohne Spuren zu hinterlassen. Bei der Llama 3 Entwicklung waren über 66% aller Training-Unterbrechungen auf Hardware-Fehler zurückzuführen. Betroffen sind vor allem SRAMs, HBMs, Processing Grids und Network-Hardware.
Detection-Mechanismen im Einsatz
Meta nutzt drei Systeme: Fleetscanner führt periodische Tests alle 45-60 Tage durch, Ripple co-lokalisiert Tests mit Workloads für schnellere Fleet-Abdeckung in Tagen statt Monaten, und Hardware Sentinel analysiert Kernel-Exceptions ohne dedizierte Tests – 41% effektiver als reine Testing-Ansätze. Soweit ich das sehen kann, sind alle Tools nicht öffentlich verfügbar.
Für Training-Workloads setzt Meta auf Hyper-Checkpointing (häufigere Checkpoints zur schnelleren Isolation korrupter Nodes), Gradient Clipping gegen NaN-Propagation, und Algorithmic Fault Tolerance direkt in den Training-Algorithmen integriert. Die Tri-variate Training Architecture nutzt Shadow-Nodes zur Verifikation – erkannte Fehler stoppen nur betroffene Nodes.
Mit steigender Chip-Komplexität treten SDCs bei etwa einem von tausend Geräten auf – deutlich häufiger als kosmische Strahlung verursachte Soft-Errors. Meta arbeitet seit 2018 an dieser Problematik und kooperiert mittlerweile mit Google, Microsoft, ARM, AMD, NVIDIA und Intel an Industry-Standards.
How Meta keeps its AI hardware reliable
Dataport und Phoenix: 90 Millionen Euro Lehrgeld
Die erfolgreiche E-Mail-Migration in Schleswig-Holstein hat eine teure Kehrseite: Der öffentliche IT-Dienstleister Dataport macht 90 Millionen Euro Verlust mit dem Projekt „Phoenix“ – dem digital souveränen Arbeitsplatz, der Microsoft ersetzen sollte. Der NDR berichtet über politische Forderungen, während Dataport eine ausführliche Stellungnahme veröffentlicht.
SPD und FDP im schleswig-holsteinischen Landtag fordern Aufklärung. Kianusch Stender (SPD): „Steuerzahler haben ein Recht darauf, dass öffentliche Mittel effizient eingesetzt werden.“ Bernd Buchholz (FDP) wird deutlich: „90 Millionen Euro sind kein Spielgeld – das ist mehr als ein Drittel der Scheuer-Maut-Summe.“
Der Bund der Steuerzahler kritisiert „mangelnde Koordinierung und planloses Vorgehen“. Das zentrale Problem: Dataport entwickelte Phoenix jahrelang, die Arbeit floss in das Bundesprojekt „OpenDesk“ ein – aber Dataport wurde dafür nicht bezahlt.
In ihrer offiziellen Stellungnahme zeichnet Dataport ein differenzierteres Bild:
Phoenix entstand 2019 aus der Debatte um digitale Souveränität, ausgelöst durch Trumps erste Regierung. Der IT-Planungsrat betonte 2020 „die große strategische Bedeutung“ digitaler Souveränität. Eine PwC-Studie im Auftrag des BMI (2019) empfahl explizit „Diversifikation und Open-Source-Alternativen“ zu Microsoft.
Im Jahr 2022 verschob Russlands Ukraine-Angriff die Prioritäten fundamental. Haushaltsmittel für Phoenix wurden gekürzt und in Verteidigungshaushalte umgesteuert. Die Bereitschaft zur Mitfinanzierung durch die Länder blieb „eine echte Herausforderung“.
Das BMI gründete Ende 2022 das ZenDis (Zentrum für Digitale Souveränität) als 100%-Bundestochter. Anfang 2024 übergab Dataport die Community-Version von Phoenix an ZenDis, die sie als „OpenDesk“ weiterführt. Heute nutzen 160.000 User OpenDesk – gut die Hälfte geht auf Dataports Vorarbeit zurück.
Da zwei öffentliche Anbieter am Markt nicht wirtschaftlich agieren können, gab Dataport Phoenix auf. Sonderabschreibung 2024: 36,5 Mio. Euro. Der Gesamtverlust von 90 Mio. Euro ist laut Dataport „eine Folge einer strategischen Umorientierung des Bundes, aber auch eigener Fehler in der Durchführung“.
Positiv daran: Keine Nachschusspflicht für die beteiligten Bundesländer. Das operative Ergebnis 2025 wird erreicht. Dataport analysierte die Fehler kritisch und setzte bis September 2025 einen Maßnahmenplan um – vom Programm-Management bis zum Risikomanagement.
Dies ist ein Lehrstück über die Komplexität öffentlicher IT-Projekte. Phoenix war technisch erfolgreich – OpenDesk mit 160.000 Nutzern beweist das. Das Desaster war politisch-organisatorisch: Zu wenig verbindliche Finanzierungszusagen, geopolitische Prioritätsverschiebungen, und am Ende zwei konkurrierende öffentliche Anbieter (Dataport vs. ZenDis).
Die tragische Ironie daran: Während die E-Mail-Migration als Erfolg gefeiert wird, zahlt Dataport im Hintergrund 90 Millionen Euro Lehrgeld. Der Bund der Steuerzahler hat jedenfalls einen Punkt hier: „Der, der es entwickelt, muss es auch bezahlt bekommen.“ Digitale Souveränität braucht mehr als gute Technik – sie braucht klare Governance und verbindliche Finanzierungsstrukturen.
Abschluss des Programms Phoenix: Dataport übergibt digitalen Arbeitsplatz an ZenDis
Omarchy: DHHs Linux ein Sicherheits-Albtraum in Bash-Scripts?
David Heinemeier Hansson (DHH), Rails-Erfinder und 37signals-Co-Founder, hab ich hier ja öfter schon erwähnt. Zum Thema Cloud-Exit hat Basaecamp ja einiges gemacht – oder auch mit Kamal nun eine coole Container Runtime am Start.
Vor einer Weile hat er mit Omarchy eine Arch-Linux-Konfiguration veröffentlicht, die von Framework (Laptops) und Cloudflare gepusht wird. Der genaue Blick eines Linux Entwicklers zeigt allerdings: Ein offensichtlich schlecht durchdachtes Projekt – vor allem im Bereich Sicherheit.
- Die Firewall ist standardmäßig AUS: Trotz vorkonfigurierter Regeln läuft die Firewall nicht – bis v3.1.0 musste sie manuell aktiviert werden. Die einzige Sicherheitsmaßnahme neben Disk-Encryption.
- Schwache Passwörter erlaubt: Der Installer akzeptiert „install“ als Passwort für User-Account und Disk-Encryption.
- 10 Sudo-Versuche statt 3: Erhöhte Retry-Limits laden zu Brute-Force-Attacken ein.
- SSH-Port offen, unkonfiguriert: Port 22 offen, sshd_config ohne sichere Defaults.
- Software via curl | sh: Statt Package-Manager werden Scripts aus dem Internet geladen.
Zudem nutzt Omarchy Rails-inspirierte Bash-Migrations ohne Exception-Handling, Status-Checks oder Validierung. Commands laufen sequentiell weiter, auch wenn vorherige fehlschlagen. Und ja, viel „Curl | sh“, das man heute ja oft bei diversen Projekten sieht.
Fehlende Basis-Features
Kein RAID1, keine Swap-Partition (Hibernation defekt), kein Power-Management (tlp, laptop-mode), kein Cron, kein Mail-Command, und witzigerweise auch kein Ruby vorinstalliert – obwohl DHH Rails ja mal erfand.
Omarchy priorisiert Form über Funktion. Framework und Cloudflare unterstützen es ohne Due Diligence – eine Ohrfeige für echte Distro-Maintainer. Daher sollte man sich vermutlich eher Manjaro, Fedora Workstation oder Ubuntu Desktop anschauen.
Cookie Zustimmung als Browser Funktion
Ein Artikel auf NEDNEX analysiert das fundamentale Problem mit Cookie-Bannern und schlägt eine radikale Lösung vor: Die Verantwortung sollte von Millionen Websites auf eine Handvoll Browser verlagert werden.
Cookie-Banner nerven nicht nur – sie sind ineffektiv. Consent Fatigue führt dazu, dass User blind auf „Alles akzeptieren“ klicken. Kleine Betreiber werden mit rechtlichen und technischen Hürden konfrontiert, während Großkonzerne teure Consent Management Platforms einsetzen. Die aktuelle Regulierung bestraft ironischerweise die Falschen und am Ende blickt meiner mehr durch, was er eigentlich geklickt hat.
Der Vorschlag ist daher simpel: User definieren ihre Datenschutz-Präferenzen einmalig im Browser – von „nur essentiell“ bis „personalisierte Werbung“. Der Browser setzt diese Wahl dann automatisch durch, blockiert unerlaubte Cookies und macht Banner überflüssig.
Statt Millionen Websites zu kontrollieren, müssten Regulierer nur einige wenige Browser-Hersteller überwachen. Entwickler wären von rechtlichen Compliance-Pflichten befreit. User hätten echte Kontrolle – und ein schnelleres, saubereres Web-Erlebnis und keiner müsste mehr für die teils abartig teuren Consent Lösungen bezahlen.
Das erinnert an frühere Diskussionen zu Cookie-Banner-Gesetzen und Mozillas Ansatz, Cookie-Banner automatisch abzulehnen (Firefox, 2023) Die Idee ist komplett logisch – an der Umsetzung hapert es mal wieder.
Wie fändest du eine solche Lösung?
The Internet’s Biggest Annoyance: Why Cookie Laws Should Target Browsers, Not Websites
Fal.ai: 4 Milliarden Bewertung für AI Modell Hosting
Das AI-Startup Fal.ai hat in einer neuen Finanzierungsrunde $250 Millionen eingesammelt und wird nun mit über 4 Milliarden Dollar bewertet – das ist mehr als eine Verdopplung gegenüber der Series C vor nur drei Monaten ($1,5 Milliarden). Kleiner Perkins und Sequoia führten die Runde an.
Die 2021 von Ex-Coinbase und Amazon Engineers Burkay Gur und Gorkem Yurtseven gegründete Plattform setzt auf Multimedia-AI statt Text-Modelle. Der Fokus auf Geschwindigkeit bei der Optimierung von Modellen wie Stable Diffusion zahlte sich aus: Annual Recurring Revenue stieg von $10 Millionen auf $95 Millionen, die Developer-Base vervierfachte sich auf über 2 Millionen.
Fal.ai hostet über 600 Image-, Video-, Audio- und 3D-Modelle auf einer GPU-Cloud mit tausenden Nvidia H100/H200 Chips. Die serverless Infrastruktur lässt sich via APIs oder Enterprise-Clustern nutzen. Adobe, Canva, Shopify und Perplexity setzen bereits auf die Plattform für Content-Generierung.
Mit fast $450 Millionen Gesamtkapital differenziert sich Fal.ai von Breitband-Anbietern wie Google, Microsoft und CoreWeave durch den Fokus auf Creative-Tech. Frühere Investoren sind Andreessen Horowitz, Bessemer und First Round Capital.
Nächste Woche habe ich Nicolai Klemke von Neural Frames im Podcast zu Gast – er ist Heavy User von fal.ai mit seinem AI Music Video SaaS.
Schmunzelecke
Passend zur AWS Downtime ein Auszug aus Southpark Episode 6, Season 12 – Kyle fixed hier das Internet….
Auch ganz witzig – hier auf YouTube gibt es einen Live Stream von einem Wasserloch in Namibia.
💡 Link Tipps aus der Open Source Welt
OpenKruise – Advanced Kubernetes Workload Management
OpenKruise ist ein CNCF Incubating-Projekt, das Kubernetes um fortgeschrittene Controller für Workload- und Application-Management erweitert. Das Projekt bietet erweiterte Funktionen, die über die Standard-Kubernetes-Controller hinausgehen.
Features:
- Advanced Workloads: CloneSet für Stateless-Apps, Advanced StatefulSet/DaemonSet mit In-Place-Updates und konfigurierbaren Rollout-Strategien
- Sidecar Management: SidecarSet für zentrale Sidecar-Definition und -Updates, Container Launch Priority für Startup-Reihenfolge
- Multi-Domain Management: WorkloadSpread für Pod-Verteilung über verschiedene Node-Pools, Availability Zones oder Architekturen (x86/ARM)
- Enhanced Operations: ContainerRecreateRequest für Container-Neustarts ohne Pod-Neustart, ImagePullJob für Pre-Pulling von Images
- Application Protection: PodUnavailableBudget zum Schutz vor Service-Unterbrechungen, Schutz vor Cascading Deletions
OpenKruise löst typische Kubernetes-Limitierungen wie fehlende In-Place-Updates, eingeschränkte Rollout-Strategien und komplexes Sidecar-Management. Die Controller sind als Ergänzung zu Standard-Kubernetes konzipiert und backward-compatible. Weitere Infos und Features findest du auf der OpenKruise Website.
Das Projekt eignet sich besonders für Teams, die erweiterte Deployment-Strategien und granularere Kontrolle über ihre Kubernetes-Workloads benötigen. Weiß aber nun auch nicht, warum man nicht versucht, diese Themen upstream zu mergen? zu nischig? Merge dauert zu lange?
https://github.com/openkruise/kruise
Stategraph – Terraform State als Graph-Datenbank
Stategraph ist ein angekündigtes Projekt von Terrateam, das Terraforms State-Files durch eine PostgreSQL-basierte Graph-Datenbank ersetzen will. Der Ansatz: Statt globalem File-Lock gibt es Resource-Level-Locking auf einem Dependency Graph.
Features:
- Graph-basierte State-Speicherung in PostgreSQL
- Multi-Version Concurrency Control (MVCC)
- Parallele Ausführung unabhängiger Changes
- SQL-Queries auf Infrastructure State
- Incremental Refresh nur betroffener Ressourcen
- Terraform/OpenTofu-kompatibles Backend
Teams blockieren sich bei Terraform üblicherweise durch einen globalen Lock auf einer JSON-Datei – selbst bei unabhängigen Änderungen. Stategraph löst dies durch Resource-Level-Locking: Nur betroffene Subgraphen werden gesperrt, unabhängige Operationen laufen parallel.
Achtung: Das Projekt ist in aktiver Entwicklung und sucht Design-Partner. Keine Info zu Lizenzierung oder Open-Source-Status. Die Website zeigt nur bisher nur Konzepte, Blog Einträge und Mock-UIs. Technisch solider Ansatz für echte Enterprise-Probleme. Ohne Verfügbarkeitsinfos bleibt es aber vorerst ein interessantes Konzept zum Beobachten.
❓ 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: