Willkommen zu allesnurgecloud.com – Ausgabe #204
Falls du den Newsletter letzte Woche vermisst hast, schau doch mal in dein SPAM Spam. Es war etwas naiv zu denken, man könne einfach so eine Phishing Domain in einer E-Mail erwähnen. Zumindest bei allen G-Mail/Workspace Accounts ist die Mail im Spam gelandet.
Naja, passiert mir halt auch dann mal, dass ich da nicht aufpasse.
Mal schauen wie es diese Woche klappt, der Phishing Zug im NPM Ökosystem hat ja leider nochmal fahrt aufgenommen.
Die Kündigung von Jimmy Kimmel würde ich normalerweise nicht erwähnen – überraschend fand ich, dass offensichtlich die Disney+ Cancellation Page nicht mit dem Ansturm klar kam und nicht mehr funktioniert hat. Da hat wohl jemand die Auto-Scaling Gruppe deaktiviert oder das auf einem Raspberry Pi betrieben – vielleicht auf dem, auf dem auch die Meta KI läuft? (s.u.).
Falls du selbst über interessante Artikel stolperst, schick mir einfach einen kurzen Hinweis als Antwort auf diese Mail – danke!
Happy Bootstrapping Podcast
In der aktuellen Folge 139 spreche ich nach über 2 Jahren erneut mit dem Stuttgarter Lukas Hermann, der stagetimer.io inzwischen auf über 20.000€ MRR verdoppelt und ein neues SaaS, RundownStudio, gestartet hat. Witzigerweise schicke ich Lukas immer Instagram/YouTube Videos und Screenshots, wenn ich sein Tool im Einsatz sehe – zuletzt bei der Trump Rallye oder auch bei der Fast & Curious Podcast Tour.
Wir sprechen auch über „Gründen in Deutschland“ und warum er hierzu aufklärt – unbedingt reinhören in Folge 139.
Ü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:
NPM Supply Chain Attack: „Shai-Hulud“ erreicht 500+ Pakete
Die NPM Kompromittierung von @ctrl/tinycolor aus der letzten Ausgabe war nur der Anfang. Die „Shai-Hulud“ Supply Chain Attack hat sich mittlerweile auf über 500 npm Pakete ausgebreitet – inklusive mehrerer CrowdStrike-Packages. Der selbstreplizierende Wurm nutzt kompromittierte Maintainer-Accounts zur exponentiellen Verbreitung.
Die Angriffsmechanik
Die Malware durchlief 7 Evolutionsstufen, jede Version ausgefeilter als die vorherige. Das Herzstück: Ein 3.6MB großes bundle.js Script, das während der Installation aktiviert wird. Es nutzt das legitime Tool TruffleHog zum Credential-Scanning, erstellt GitHub Actions Backdoors und repliziert sich automatisch auf weitere Pakete des Maintainers. Über TruffleHog hatte ich im März in Ausgabe 180 berichtet.
Besonders perfide: Die gestohlenen Credentials landen in öffentlichen GitHub-Repositories namens „Shai-Hulud“. Eine GitHub-Suche zeigte hunderte solcher Repos – die Daten sind für jeden einsehbar – heute am Freitag konnte ich nur noch 3 betroffene Repos sehen.
Prominente Opfer
Die Liste liest sich wie ein Who’s Who der npm-Welt:
- @ctrl/tinycolor mit 2.2 Millionen wöchentlichen Downloads
- Mehrere @crowdstrike/ Pakete (commitlint, glide-core, logscale-*)
- ngx-bootstrap, ngx-toastr, react-jsonschema-form
- Hunderte Pakete über @nativescript, @operato, @things-factory
Gegenmaßnahmen: Der neue Defense Stack
Verzögerte Installation mit pnpm
pnpm 10.16 führt eine clevere Schutzfunktion ein: minimumReleaseAge verzögert die Installation neuer Paketversionen. Mit minimumReleaseAge: 1440 installiert pnpm nur Pakete, die mindestens 24 Stunden alt sind – genug Zeit, um kompromittierte Versionen zu entdecken – hoffentlich!?
yaml
minimumReleaseAge: 1440
minimumReleaseAgeExclude:
- webpack # Ausnahmen für kritische PaketePre-Install Auditing
Das Open-Source Tool npq prüft Pakete VOR der Installation gegen die öffentloche CVE-Datenbank von snyk.io und analysiert verdächtige Merkmale wie Pre/Post-Install Scripts:
bash
npq install expressSofortige Säuberung
Betroffene Systeme brauchen eine gründliche Bereinigung:
- Suche nach der Backdoor-Datei shai-hulud-workflow.yml in allen Repos
- Prüfung auf verdächtige GitHub-Branches namens „shai-hulud“
- Hash-Überprüfung der bundle.js Dateien
- Rotation ALLER Credentials (npm, GitHub, AWS, GCP, Azure)
Cloud-Infrastruktur auditieren
Die Malware zielt speziell auf AWS Secrets Manager und GCP Secret Manager. Tools wie AWS CloudTrail und GCP Cloud Logging helfen bei der forensischen Analyse. Sucht nach verdächtigen API-Calls wie GetSecretValue oder ListSecrets während des Infektionszeitraums.
Kommerzielle Anbieter haben auch schnell reagiert: StepSecurity bietet NPM Package Cooldown Checks und Runtime-Monitoring. Socket.dev hat die Malware früh erkannt und dokumentiert.
Was wir daraus lernen
Die Angreifer missbrauchen vertrauenswürdige Tools (TruffleHog) und legitime Infrastruktur (GitHub) für ihre Zwecke. Die Selbstreplikation zeigt: Ein kompromittiertes Paket kann das gesamte Portfolio eines Maintainers infizieren.
Best Practices ab sofort:
- 24-48 Stunden Cooldown für neue Paketversionen
- Separate CI/CD Tokens mit minimalen Rechten
- Branch Protection Rules gegen Force-Pushes aktivieren
- GitHub Secret Scanning einschalten
- Keine automatischen Dependency Updates ohne Review
Supply Chain Security ist kein Nice-to-have mehr. Mit 500+ kompromittierten Paketen ist das der größte npm-Angriff seit langem – ode gar jemals – und die Kampagne läuft noch. Die Community reagiert schnell, aber der Schaden zeigt: Wir brauchen strukturelle Änderungen im npm-Ökosystem.
Für weitere Informationen, mehr Details und Links lohnt sich für dich ein Blick in diesen Hacker News Thread – aktuell knapp 1000 Kommentare und viele Insights.
Ongoing Supply Chain Attack Targets CrowdStrike npm Packages
Nvidia kauft Intel-Anteile für 5 Milliarden Dollar
Die Chip-Industrie erlebt gerade ihr „Katzen und Hunde leben zusammen“-Moment: Nvidia investiert 5 Milliarden Dollar in Intel und erwirbt damit etwa 5% der Anteile zu $23.28 pro Aktie. Intel-Aktien schossen im vorbörslichen Handel um 33% nach oben.
Die Partnerschaft umfasst zwei Hauptprodukte:
- Intel x86 RTX SOCs für Gaming-PCs: x86-CPU-Chiplet plus Nvidia RTX-GPU-Chiplet, verbunden via NVLink (14x mehr Bandbreite als PCIe)
- Custom x86 Datacenter-CPUs: Intel baut maßgeschneiderte Prozessoren für Nvidias AI-Produkte
Technische Details
Die Gaming-Chips zielen auf Thin-and-Light-Laptops und Small-Form-Factor-PCs. Anders als Intels gescheiterte Kaby Lake-G Kooperation mit AMD (2017-2019) nutzen die neuen Chips:
- NVLink statt PCIe für CPU-GPU-Kommunikation
- Uniform Memory Access (UMA) – beide Chips greifen auf denselben Speicher zu
- Nvidia übernimmt die GPU-Treiber selbst
Die ganze Aktion zeigt: Intel ist in der Krise – nicht mehr in den Top 10 der Chiphersteller laut CEO Lip-Bu Tan. Diese Investitionen stabilisieren das Unternehmen:
- US-Regierung: $10 Milliarden (9.9% Anteil zu $20.47)
- Nvidia: $5 Milliarden (5% Anteil zu $23.28)
- Softbank: $2 Milliarden (zu $23.00)
Jensen Huang spricht von einer „Fusion zweier Weltklasse-Plattformen“. Für AMD wird’s ungemütlich – sie kämpfen jetzt gegen Intel (79% Marktanteil bei Laptop-CPUs) plus Nvidia (92% bei Gaming-GPUs).
Die Produkte kommen frühestens in einem Jahr, wahrscheinlich später. Nvidia bleibt bei seinen ARM-basierten Grace-Prozessoren committed – die Intel-Partnerschaft ist nur additiv.
Das klingt irgendwie weniger wie eine Partnerschaft – eher wie eine Rettungsaktion mit Vorteilen für beide Seiten. Intel bekommt dringend benötigtes Kapital und Nvidia-Technologie, Nvidia sichert sich Einfluss auf die x86-Zukunft und Custom-Silicon für seine Datacenter-Dominanz.
Nvidia buys $5 billion in Intel stock in seismic deal
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)
Drei Jahre 100% Remote Arbeit im Engineering Kiosk Podcast
In Folge 213 des Engineering Kiosk teilt Andy Grunwald seine Erfahrungen aus drei Jahren vollständig remote bei Cloudflare. Co-Host Wolfgang Gassler nutzt die Chance für ein tiefgehendes Interview. Andys Bilanz: 8 von 10 Punkten – aber die Details offenbaren eine komplexe Realität.
Die neurologische Komponente
Nach Konferenztagen ist Andy deutlich erschöpfter als früher. Die fehlende tägliche soziale Interaktion verändert messbar etwas: „Du sitzt acht Stunden alleine vor dem Computer. Dabei verdrahtet sich dein Kopf ein bisschen anders.“ Die berühmten Kaffeemaschinen-Gespräche? 30-40% davon braucht man eigentlich nicht – den Rest holt sich Andy gezielt, wenn benötigt.
Proaktivität oder Untergang
Der kritischste Punkt: „Keiner weiß, dass du existierst. Du musst wirklich proaktiv sein und Probleme lösen.“ Ohne Überkommunikation wird man zur Nummer auf der Payroll. Andy nutzt interne Blogs, Department-Channels und gezielte Sichtbarkeit für sein Team. Als Engineering Manager holt er Teammitglieder aktiv in Chats mit höheren Management-Ebenen.
Wolfgang’s provokante These
Wolfgang bringt einen interessanten Gedanken ein: „Die Remote-Arbeitsweise ist eigentlich die bessere Office-Arbeitsweise“ – alle Skills, die man remote braucht (Überkommunikation, asynchrone Arbeit, Dokumentation), würden auch jedes Office-Setup verbessern.
Zeitzonen-Management und Isolation
Morgens Asien, mittags Fokuszeit, abends Amerika. Die Isolation bleibt trotzdem real – Sport 3-4x wöchentlich und aktive Pflege privater Kontakte werden essentiell.
Das überraschende Fazit
„Ich habe fast das Gefühl, dass es anstrengender ist, 100% remote zu arbeiten als im Büro.“ Kein heiliger Gral, sondern ein Trade-off zwischen einzigartigen Karrierechancen und sozialen Kosten.
Die Folge geht 1 Stunde und 6 Minute und kann ich jedem ans Herz legen. Mir fehlen noch einige Punkte – aber vieles kann ich nachvollziehen. Hybrid ist einfach nochmal deutlich schwieriger als 100 % Remote, ich denke das kommt im Podcast auch raus.
Gerade wenn Unternehmen und gerade Manager in der Regel im Office sind, so ist man „remote“ doch häufig die verlängerte Werkbank.‘
Ein verrücktes „all Remote“ Hardware Setup hat dnsmichi (arbeitet bei GitLab) am Start – das aktuelle Setup ist hier öffentlich dokumentiert – ich geh dann mal bestellen.
#213 Erfahrungen aus drei Jahren 100 % Remote … ganze ohne Büro
Atlassian kauft DX für $1 Mrd & Check Point Lakera für $300 Mio
Atlassian macht Ernst mit seiner AI-Strategie und kauft groß ein. Nach der Übernahme des Arc-Browser-Entwicklers The Browser Company Anfang September legt der australische Software-Riese jetzt nach: DX, eine Developer-Productivity-Plattform aus Salt Lake City, wechselt für $1 Milliarde den Besitzer.
Was macht DX interessant?
DX analysiert Engineering-Teams und identifiziert Produktivitäts-Bottlenecks. Gründer Abi Noda entwickelte die Plattform aus Frustration über existierende Metriken bei GitHub – sie zeigten nicht, was Teams wirklich ausbremste. Die Zahlen sprechen für sich: 350+ Enterprise-Kunden (darunter GitHub selbst), Verdreifachung der Kundenbasis jährlich, und das mit nur $5 Millionen Venture Capital.
CEO Mike Cannon-Brookes gibt zu: Nach drei Jahren erfolgloser interner Entwicklung war klar – kaufen statt bauen – damit ist die Atlassian Compass Plattform gemeint – kennst du nicht, oder? Praktisch am Ankauf: 90% der DX-Kunden nutzen bereits Atlassian-Tools.
Parallel: Check Point schnappt sich Lakera
Die Cybersecurity-Welt ist ebenfalls im Kaufrausch. Check Point erwirbt das Schweizer AI-Security-Startup Lakera für geschätzte $300 Millionen. Lakera schützt AI-Agenten und LLMs in Echtzeit – ein kritisches Thema, da AI neue Angriffsflächen schafft.
Das Besondere: Lakera wurde von Ex-Google/Meta-Experten als AI-native Security-Lösung entwickelt, nicht als nachträglich aufgepfropfte AI-Funktion. Zürich wird somit wohl zu Check Points globalem AI-Security-R&D-Zentrum.
Etablierte Tech-Konzerne machen die Schatulle auf und kaufen sich also AI-Expertise ein, statt sie jahrelang selbst zu entwickeln.
Atlassian acquires DX, a developer productivity platform, for $1B
Webserver auf Wegwerf-Vape
Bogdan Ionescu hostet einen funktionierenden Webserver auf einer Wegwerf-Vape. Der Link beschreibt die Vorgehensweise – die eigentliche Website ist dann hier – du brauchst eventuell etwas Geduld beim Laden. Die Hardware ist absurd überdimensioniert für Einweg-Produkte: Ein PY32F002B mit 24MHz Cortex-M0+, 24KB Flash, 3KB RAM – mehr Power als Computer der 80er Jahre.
Der technische Hack
Bogdan nutzt Semihosting (ARM syscalls) zusammen mit SLIP aus der Modem-Ära. PyOCD leitet über Telnet, socat erstellt ein virtuelles TTY, Linux macht daraus eine Netzwerkverbindung. Ergebnis: 20ms Ping, 160ms Ladezeit.
Hardware-Verschwendung deluxe
Die Specs:
- USB-C Ladeport
- Wiederaufladbare Lithium-Batterie
- Debug-Pins (sogar beschriftet!)
- Genug Power für uIP TCP/IP-Stack
Hacker News reagiert mit über 460 Kommentarenwie gewohnt sehr unterschiedlich auf den Artikel und die Vorgehensweise von Bogdan. User SXX empfiehlt chinesische UZ801 4G Dongles für 5 Dollar mit 512MB RAM als Alternative. jsheard warnt vor Vapes mit Touchscreens: „It’s probably only a matter of time before they start running Android.“
Diese Geräte sind technisch wiederverwendbar, werden aber als „disposable“ verkauft. In UK wurden sie „verbannt“ – Hersteller reagierten mit billigen, nicht-standardisierten Ladeports.
Der Vape-Server überlebte den HN-Traffic erstmal nicht (5% Success-Rate mit nginx davor). Trotzdem beeindruckend für Hardware, die eigentlich im Müll landen sollte. Der Code für das Projekt ist auf GitHub öffentlich einsehbar.
Vapest du noch oder hostest du schon einen LLM Cluster darauf?
Hosting a WebSite on a Disposable Vape
Kubernetes auf Bare Metal
Die Kollegen von Meltcloud analysieren in diesem Blog Artikel, warum Teams wieder verstärkt Kubernetes direkt auf Hardware betreiben wollen oder sollten – und welche Herausforderungen dabei warten.
Die Motivation: Weg mit dem Hypervisor
Teams eliminieren die Virtualisierungsschicht aus mehreren Gründen:
- Direkte GPU-Zugriffe für AI/ML-Workloads ohne Performance-Verlust
- Keine doppelten Control-Planes (Hypervisor + Kubernetes)
- Unabhängigkeit von VMware-Lizenzkosten nach der Broadcom-Übernahme
- SR-IOV und SmartNICs für latenzempfindliche Netzwerk-Workloads
Die vier Knackpunkte
1. Oversized Nodes: Moderne Server mit 64 Cores und 1TB RAM überfordern Kubernetes. Tests zeigen: Ab 1.200 Pods pro Node explodiert die Scheduling-Latenz, systemd wird zum Bottleneck. Die Hardware könnte Tausende Pods hosten, aber kubelet macht bei ~500 schlapp.
2. Verschwendete Control-Planes: Drei dedizierte Bare-Metal-Server für Control-Plane-Components, die nur wenige GB RAM brauchen? Massive Ressourcenverschwendung. Hosted Control Planes (Kamaji, Hypershift) helfen, aber: Wer hostet die erste Control-Plane?
3. Worker-Management: Ohne Cloud-Automatisierung wird jeder physische Server zur operativen Herausforderung. Firmware, OS-Installation, kubelet-Bootstrap – alles manuell. Configuration Drift vorprogrammiert.
4. Cluster-as-a-Service unmöglich: Teams wollen dedizierte Cluster, aber auf Bare Metal bedeutet das dedizierte Hardware. Teuer und unflexibel.
Die Zukunft liegt vielleicht in der Kombination mehrerer Technologien: Immutable OS-Images wie Talos Linux für reproduzierbare Worker, vCluster für virtuelle Isolation innerhalb shared Clusters, und KubeVirt für VM-Worker – womit man ironischerweise wieder Virtualisierung einführt, aber diesmal unter Kubernetes-Kontrolle. Meltcloud selbst setzt auf Unified Kernel & System Images mit atomaren Updates, während andere Projekte ähnliche Wege gehen. Der Trend ist klar: Bare Metal ja, aber mit Cloud-ähnlichen Abstraktionen darüber.
Da mich mal interessiert hat, wie man die Provisionierung der Server funktioniert, habe ich den Autor und meltcloud CEO Matthias Winzeler mal angehauen und er hat mich auf diese „Enrollment“ Page verwiesen. Am einfachsten geht das ganze über ein spezielles Enrollment Image, welches sich dann beim meltcloud Service „Nest“ anmeldet und dann kann es auch schon losgehen. Matthias hat einen zweiten Artikel angekündigt, den bringe ich dann nächste woche.
Kubernetes on Bare Metal: The Four Hard Problems
PHP: 73.4% aller Websites setzen auf die „Boring Technology“
Die aktuellen W3Techs-Zahlen zeigen: PHP läuft auf 73.4% aller Websites mit bekannter Server-Side-Sprache. Ja, richtig gelesen – fast drei Viertel des Webs. Während alle über AI und Rust reden, macht PHP einfach seinen Job.
Die Version-Verteilung überrascht
- PHP 8: 50.9% (endlich über die Hälfte!)
- PHP 7: 39.1% (stirbt langsam aus)
- PHP 5: 9.9% ( fast 10% auf einer Version von 2014!)
- PHP 4: 0.1% (archaeologische Funde)
Dass noch knapp 10% auf PHP 5 laufen, ist bedenklich – die letzte Version kam 2018, Support endete 2019. Das sind potenzielle Sicherheitslücken auf Millionen von Websites.
Die Großen vertrauen PHP
Microsoft.com, Facebook.com (Meta nutzt ihre eigene HHVM/Hack-Variante), Wikipedia, WordPress.org – alles PHP-betrieben. Dem ein oder anderen Leser ist aus älteren Artikeln wie hier bekannt, dass ich auf Boring Technology stehe – das machen wohl auch andere. Bewährte, langweilige Technologie schlägt oft den neuesten Hype.
Warum PHP nicht totzukriegen ist
PHP ist das perfekte Beispiel für „Choose Boring Technology“ – es funktioniert, ist überall verfügbar, hat eine riesige Community und löst reale Probleme. Während wir hier also über Kubernetes auf Bare Metal philosophieren, deployed der Großteil der Welt weiterhin PHP-Apps auf Shared Hosting für 5€/Monat.
Die Lehre: Manchmal ist langweilig genau richtig oder auch „it depends“.
Usage statistics of PHP for websites
$130.000 Crypto-Scam: Wenn Google Authenticator zur Falle wird
David Scoville arbeitet in Tech, designt Authentication-Systeme – und verlor trotzdem $130.000 an Betrüger. Seine Geschichte auf Substack ist eine Warnung an alle, die glauben, sie wären zu schlau für Phishing.
Der perfekte Sturm
Ein Anruf aus Pacifica, CA. Der „Google Support“ meldet: Jemand hat eine Sterbeurkunde eingereicht, um Scovilles Account zu übernehmen. Klingt absurd? Der Clou: Eine E-Mail von legal@google.com bestätigt die Story. In der iOS Gmail-App sah alles legitim aus – das @google.com prominent angezeigt.
Als der Anrufer um einen Verifikationscode bat („um zu beweisen, dass Sie noch leben“), teilte Scoville ihn mit. Fatal: Der Betrüger hatte bereits sein Passwort (vermutlich aus den 16 Milliarden geleakten Passwörtern) und umging mit dem Code die 2FA.
Die technische Katastrophe
Google Authenticator synchronisiert Codes standardmäßig in die Cloud. Mit Zugriff auf Scovilles Gmail hatte der Angreifer damit alle seine 2FA-Codes. Binnen 40 Minuten: Coinbase geplündert, ETH verschoben, $80.000 weg (heute $130.000 wert).
Googles Versagen
- Spoofing-Filter versagten: E-Mails mit gefälschtem @google.com-Absender kamen durch
- Cloud-Sync als Schwachstelle: Google Authenticator ist keine echte 2FA mehr, wenn die Codes in derselben Cloud liegen wie das kompromittierte Gmail – auf die tolle Alternative 2FAS hatte ich schon mehrfach hier hingewiesen.
Die Lehren
- Niemals Verifikationscodes teilen – auch nicht bei „Dringlichkeit“
- Google Authenticator Cloud-Sync deaktivieren oder Alternative nutzen
- Passwörter regelmäßig ändern (Scoville hatte seins jahrelang nicht geändert)
- Bei verdächtigen Anrufen: Auflegen, selbst bei der Firma anrufen
Ein Tech-Profi, der Authentication-Systeme designed, fiel auf Social Engineering rein. Die Kombination aus geleakten Passwörtern, überzeugender Spoofing-Mail und Googles Cloud-Sync machte aus einem Moment der Panik eine Katastrophe.
Im Kommentar berichtet ein User, das er ebenfalls betroffen war (Infos bei LinkedIn) – glücklicherweise hatte er keine Coins mehr bei Coinbase – das Glück hat nicht jede(r).
I Was Scammed Out of $130,000 — And Google Helped It Happen
„Die Kochen auch nur mit Wasser“
Bei der Meta AI Demo ist ein bisschen was schiefgegangen – zweimal. Live Demos sind immer schwierig, ich versuche die immer irgendwie einzubauen, aber auch bei Meta, wo das sicher gut vorbereitet ist, passieren dann „Live“ eben auch Fehler – Video geht um die 2 Minuten und ist hier auf YouTube.
Aktuell schiebt man die fehlgeschlagene Demo übrigens auf eine Self DDoS, die „Hey Meta start Live AI“ im Raum ausgelöst haben soll:
So here’s the story behind why yesterdays live #metaconnect demo failed – when the chef said “Hey Meta start Live AI” it activated everyone’s Meta AI in the room at once and effectively DDOS’d our servers
Quelle twitter.com
Naja, ich glaube, das irgendwie nicht so ganz. Lief das System aus Sicherheitsgründen bei Mark auf dem Raspberry Pi zu Hause?
Schmunzelecke
Ok, damit lande ich vielleicht wieder in den Spam Foldern… falls du deine Security Abteilung ärgern willst, dieser Link Shortener baut legitime URLs so um, als sehen sie wie „böse“ URLs aus. Man kann zwischen verschiedenen Kategorieren wählen, wie etwa „Crypto“, „Tech“, „Gambling“ und ein paar mehr – allesnurgecloud.com wäre also auch hier erreichbar….
💡 Link Tipps aus der Open Source Welt
Cachey – High-Performance Read-Through Cache für S3
Cachey ist ein Open-Source Read-Through Cache für S3-kompatiblen Object Storage, geschrieben in Rust. Entwickelt von s2.dev, um ihre Streaming-Plattform zu skalieren und S3-Latenz zu minimieren.
Features:
- Hybrid Memory+Disk Cache (powered by foyer)
- Simple HTTP API (nicht S3-kompatibel!)
- 16MB Page-aligned Reads für Effizienz
- Request Coalescing für identische Pages
- Hedged Requests gegen S3 Tail Latency
- Multi-Bucket Support für redundante Lookups
- Streaming Response für große Objekte
- Kubernetes-ready mit Auto-Scaling
- Rendezvous Hashing für Key Affinity
s2.dev nutzt Cachey für ihre „Kafka meets S3“-Plattform, um S3-Latenz zu reduzieren und Read-Throughput zu skalieren (Motivation haben die Macher auf Reddit geteilt). Die Herausforderung: Recent Records waren nur beim Stream-Owner verfügbar, was Cross-Zone-Traffic und Skalierungsprobleme verursachte. Cachey ermöglicht nun direktes Lesen aus S3 mit Cache-Layer, reduziert Operations-Kosten und umgeht RPS-Limits. Die Page-Cache-Inspiration aus OS-Design macht es effizient für sequentielle Reads.
Die Reddit-Community ist wie immer geteilter Meinung: Einige sehen Potenzial für generische S3-Caching-Lösungen, andere kritisieren den Ansatz als zu generisch. Der Hauptkritikpunkt: Spezialisierte Datenbank-Engines (ClickHouse, etc.) nutzen domänenspezifisches Wissen für effizienteres Caching. Ein Kommentator merkt an, dass S3 selbst schon Caches hat und generische Ansätze wenig Mehrwert bieten. Interessante Diskussion entsteht um „Page Cache vs Direct IO“ für Datenbanken – Cachey ist definitiv im Page-Cache-Lager.
Cachey ist eine interessante Lösung für spezifische S3-heavy Workloads – ob der generische Ansatz über s2.dev hinaus Sinn macht, bleibt umstritten.
https://github.com/s2-streamstore/cachey
Crontab Guru Dashboard – Self-Hosted Cron Job Manager
Crontab Guru Dashboard ist ein kostenloses, selbst-gehostetes Open-Source-Tool zur Verwaltung von Cron Jobs mit einer modernen Web-UI. Es macht Schluss mit der Kommandozeilen-Jonglage und bringt Cron-Jobs ins 21. Jahrhundert.
Das Tool ist ein Open Source Produkt der „Cronitor“ SaaS Cronjob Monitoring Suite – interessant, dass man damit so ein großes Ding aufbauen kann – und Firmen wie Reddit, Square, Cisco und Monday das nutzen.
Features:
- Web-basierte Cron Job Verwaltung
- Jobs per Klick sofort ausführen
- Eingebaute Test-Konsole
- Laufende Jobs anzeigen und beenden
- MCP-Support für Coding Assistants
- SSH-Tunnel für sicheren Remote-Zugriff
- Systemd-Integration
- Docker-Support
- IP-Whitelisting für Zugriffskontrolle
- Auto-Update-Benachrichtigungen
Die Ein-Zeilen-Installation via curl https://crontab.guru/install | sh und der integrierte Expression Editor machen es zum perfekten Tool für alle, die regelmäßig mit Cron arbeiten. SystemD, Docker, etc. gibt es natürlich auch.
https://github.com/cronitorio/cronitor-cli
❓ 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: