Willkommen zu allesnurgecloud.com – Ausgabe #235

Diese Woche war ich auf der OMR in Hamburg, der größten Digital-Konferenz in Europa und hab viele spannende Talks gehört, Spaß gehabt und neue Menschen kennengelernt. Euch empfehlen würde ich 2 Talks, die schon auf YouTube sind. In „Beyond the AI Hype“ liefert Tech-Experte, Investor und Doppelgänger-Podcast-Host Philipp Klöckner ein Feuerwerk zum aktuellen Stand von KI, Vergleich der Modelle, Finanzierung, dem Ausbau von Datacentern und vielem mehr. Absolute Empfehlung – auch der Stil, 148 Slides in 55 Minuten abzufeuern, ist bemerkenswert (bei YouTube).

Der zweite Talk ist die „State of the Internet 2026“ Keynote von OMR Gründer Philipp Westermeyer und dem OMR Head of Content Roland Eisenbrand. Hab da einiges mitgenommen – wer sind die Gewinner, Verlierer – warum wird aber vor allem Reddit immer relevanter und was Knippex da zu suchen hat. Im Talk gibt es auch interessante Social Media Beispiele – IT Nerds werden „Let’s Skip the Bla“ bzw. IT-Praxis Dr. Bauer von Instagram kennen.

In der DB-Welt gab es einen kleinen Aufschrei, dass das beliebte pgBackRest Backup & Restore Projekt eingestellt wird – nun haben sich doch genug Sponsoren und freiwillige Helfer gemeldet, so dass der Maintainer das Projekt aufrecht erhält und weitermacht.

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

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 171 habe ich mit Julia Derndinger über ihre Arbeit als Sparringspartnerin für Unternehmer:innen gesprochen. Julia betreibt zwei Modelle parallel: 1:1-Sparring für Later-Stage-Gründer:innen ab 5 Mio. Umsatz und ihr Gründerprogramm TeamJulia für 1.000 Euro im Monat. Wir reden über das Spielfeld-Bild für die CEO-Rolle, warum sie keine Frameworks anbietet und trotzdem ausgebucht ist und wie sie auf bootstrapped vs. VC-finanzierte Unternehmen schaut. 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:

Cloud-Earnings Q1: Die AWS Hierarchie wackelt

Die großen Cloud-Sparten haben Q1 2026 reportet, und die Wachstumsraten lassen die alte Hierarchie zusehends fragwürdig wirken. Aufgefallen ist mir der Vergleich in der Doppelgänger-Tech-Talk-Folge #558, wo Philipp Klöckner durchspielt, wann Google Cloud AWS überholen könnte.

Die Zahlen im Überblick:

• AWS: +28 % auf 37,6 Mrd. US-Dollar – schnellstes Wachstum seit 15 Quartalen, Vorquartal lag bei 24 %. Backlog 364 Mrd. $.
• Microsoft Azure und andere Cloud-Services: +40 % im Intelligent-Cloud-Segment (34,7 Mrd. $), Backlog 627 Mrd. $ (+99 %).
• Google Cloud: +63 % auf 20,03 Mrd. $, ein Sprung von zuvor 48 %. Operating Income hat sich von 2,2 auf 6,6 Mrd. $ verdreifacht, Backlog auf über 460 Mrd. $ verdoppelt.

Bemerkenswert ist nicht das absolute Niveau, sondern das Tempo. AWS wächst bei einer Run-Rate von rund 150 Mrd. $ – Google bei 80 Mrd. Eine Lücke von Faktor 1,9. Bei 28 % vs. 63 % Wachstumsrate (gerundet) verdoppelt sich Google ungefähr alle anderthalb Jahre, AWS braucht dafür eher drei. Philipp Klöckner sieht Google damit zum ersten Mal ernsthaft im Rennen, ob es vor Microsoft an AWS vorbeizieht – sein Rechenmodell legt das Überholmanöver mathematisch in den Bereich von zwei bis drei Jahren, sofern sich beide Trends halten. Bin mal gespannt, erfahrungsgemäß wird das Wachstum ja eigentlich langsamer, wenn man größer wird. Gerade die Tech Konzerne beweisen aber regelmäßig das Gegenteil.

Auf der Investitionsseite spiegelt sich das wider: Google hebt CapEx auf 175–185 Mrd. $ für 2026 an, Amazon plant rund 200 Mrd. $, Microsoft zieht ebenfalls nach. Der Auftragseingang in den Backlogs zeigt, dass das Geld nicht ins Leere fließt – die Frage ist nur, wer schnell genug Hardware aufgebaut bekommt. Bei AWS und Azure spricht man inzwischen offen davon, supply-constrained zu sein.

Die Summen, die die Hypescaler für RZs ausgeben wollen, sind jedenfalls total absurd und in diesem Jahr dann höher als der Haushalt in Deutschland, wenn ich das richtig sehe.

Alphabet ups 2026 capex to as much as $190 billion, expects to ‘significantly increase’ in 2027

---

Embargopanne: Dirty Frag ohne Patch öffentlich

Nur eine Woche nach Copy Fail hat Hyunwoo Kim (@v4bel) die nächste Linux-Kernel-Privilege-Escalation enthüllt – diesmal unter dem Namen Dirty Frag (CVE-2026-43284 und CVE-2026-43500). Die Lücke gehört zur selben Bug-Klasse wie Dirty Pipe (siehe Ausgabe 55, lange her) und Copy Fail, operiert aber auf dem frag-Feld eines struct sk_buff statt auf struct pipe_buffer.

Technisch werden zwei Kernel-Pfade miteinander verkettet: xfrm-ESP Page-Cache Write (im IPsec-Subsystem, vorhanden seit Januar 2017) und RxRPC Page-Cache Write (seit Juni 2023). Beide haben denselben Effekt: Über splice() landet eine Read-only-Page-Cache-Page in einem Socket Buffer, auf der der Kernel dann in-place kryptografische Operationen ausführt – und dabei Dateien wie /etc/passwd oder /usr/bin/su im RAM überschreibt, ohne dass Schreibrechte vorhanden wären. Weil sich die beiden Varianten gegenseitig ergänzen (ESP braucht Namespace-Privileges, rxrpc ist dafür auf Ubuntu standardmäßig geladen), funktioniert der Angriff auf praktisch jeder Distribution. Ein entscheidender Punkt: Wer bereits den algif_aead-Blacklist als Copy-Fail-Mitigation eingespielt hat, ist nicht geschützt.

Besonders problematisch ist die Disclosure: Das fünftägige Embargo wurde am 7. Mai von einem unbeteiligten Dritten gebrochen, der einen eigenen PoC veröffentlichte – woraufhin Kim den vollständigen Exploit freigab. Patches existieren zum Zeitpunkt der Veröffentlichung nur im Mainline-Kernel für den ESP-Teil; rxrpc ist noch ungefixed.

Die genaue Mitigation-Sequenz findet sich direkt im README des Exploits. Achtung: Wer IPsec oder AFS/rxrpc produktiv nutzt, bricht damit seine Konnektivität. Ein Reboot ist nach dem Kernel-Patch erforderlich; der drop_caches-Befehl wirkt sofort und sollte vorsorglich ausgeführt werden.

HN-User firer brachte eine interessante Randbeobachtung: Der Copy-Fail-Entdecker hatte bei seiner Analyse stark auf KI gesetzt – und dabei genau diese verwandte Schwachstelle übersehen. „It’s a very unusual case of negative synergy, where working together hurt performance.“

Dirty Frag Writeup

---

---

EU will US-Clouds aus Behörden verdrängen

Brüssel macht Ernst – zumindest auf der Ankündigungsebene. Wie Mike Faust auf Golem unter Berufung auf einen CNBC-Bericht meldet, plant die EU-Kommission, die Nutzung US-amerikanischer Clouddienste durch die Regierungen der Mitgliedsstaaten einzuschränken. Vorgestellt werden soll das Paket zur Stärkung der technologischen Souveränität am 27. Mai 2026.

Im Kern geht es darum, Sektoren zu definieren, deren Daten zwingend auf europäischer Infrastruktur liegen müssen. Diskutiert werden laut Bericht Finanz-, Justiz- und Gesundheitsdaten – also genau jene Bereiche, in denen heute fröhlich AWS-, Azure- und Google-Cloud-Workloads laufen. Hyperscaler aus Drittstaaten sollen nicht komplett von öffentlichen Aufträgen ausgeschlossen werden, wohl aber von der Verarbeitung kritischer Daten. Auch europäische Anbieter, die unter der Haube US-Technologie nutzen, fallen unter diese Logik – ein wichtiges Detail, das Konstrukte wie Delos oder die Bundeswehr-Google-Cloud direkt trifft.

Bemerkenswert ist der Zeitpunkt. Nach dem AWS-Ausfall im Oktober und der Azure-Störung am niederländischen Wahltag ist das Argument politisch nicht mehr exotisch. Martin Loschwitz hatte in seinem viel zitierten heise-Kommentar bereits geschrieben, der perfekte Zeitpunkt für eine eigene Cloud-Infrastruktur sei vor 20 Jahren gewesen – der nächstbessere sei jetzt. Die EU scheint diese Lesart übernommen zu haben.

Skepsis bleibt angebracht. „Hoher Grad an Souveränität“ ist eine schöne Formel, aber die entscheidende Frage ist die Definition: Reicht ein EU-Rechenzentrum mit US-Mutterkonzern, oder muss der CLOUD Act tatsächlich technisch und gesellschaftsrechtlich ausgeschlossen sein? Letzteres würde den Markt deutlich umbauen, ersteres bliebe Etikettenschwindel. Bis zum 27. Mai weiß man, welche Variante Brüssel meint.

EU könnte Nutzung von US-Clouddiensten einschränken

---

TK-Studie: 20 Prozent mehr Output zuhause

Während US-Tech-Konzerne ihre Belegschaft per RTO-Mandat zurück ins Büro zwingen, liefert das Fraunhofer IAO eine Studie mit Zahlen, die die Debatte etwas nüchterner machen sollte. Josephine Hofmann und Kollegen haben zusammen mit der Techniker Krankenkasse in 2022 bis 2024 die Produktivität in der Sachbearbeitung gemessen – nicht per Befragung, sondern über die sogenannte Einzelplatzauswertung (EPAW), die bearbeitete Postkorbmeldungen und Telefonate pro Arbeitszeit erfasst.

Das Kernergebnis: Im Homeoffice werden rund 20 Prozent mehr Vorgänge bearbeitet als im Büro. Über drei Jahre hinweg blieb diese Differenz erstaunlich stabil. Auf Dienststellenebene schwankt sie allerdings zwischen 0 und 30 Prozent – die Art der Aufgabe erklärt die Unterschiede laut Studie nicht, eher Kommunikationskultur und Zusammenarbeit.

Interessanter ist der „Kipp-Punkt“: Mehr Homeoffice bedeutet nicht automatisch mehr Gesamtproduktivität. Die TK fand das Optimum bei etwa 60 Prozent Homeoffice-Anteil auf Unternehmensebene. Darüber kippt der Effekt, weil informeller Austausch, Wissenstransfer und Teamzusammenhalt – die Frühindikatoren – leiden. Eine Korrelationsanalyse über sieben Dienststellen mit aufgehobener Obergrenze ergab einen negativen Zusammenhang von p = -0,31 zwischen Homeoffice-Anteil und Gesamtarbeitslast.

Die Konsequenz ist konkret: Ab 2026 dreht die TK ihre Dienstvereinbarung um – statt einer Obergrenze von 60 Prozent Homeoffice gibt es künftig eine Untergrenze von 40 Prozent Büro-Präsenz, mit Reduktion auf bis zu 30 Prozent bei nachgewiesen guter Zusammenarbeit.

Bemerkenswert ist auch der Pendler-Befund: Bei Anfahrtszeiten unter einer Stunde halten 30 Prozent die Bürozeit für sehr wertvoll, bei über drei Stunden nur 6 Prozent. Wer das Sozialkapital eines Teams pflegen will, sollte also nicht nur über Anwesenheitsquoten reden, sondern auch über Standorte und Pendelzeiten.

Fraunhofer Studie: Höhere Produktivität im Homeoffice?

---

Chrome installiert 4 GB AI – ungefragt

Privacy-Anwalt Alexander Hanff hat in einem forensisch sauber dokumentierten Beitrag belegt, was in einschlägigen Foren seit über einem Jahr zirkuliert: Google Chrome lädt auf passender Hardware ein 4 GB großes Gemini-Nano-Modell in das Verzeichnis OptGuideOnDeviceModel – ohne Consent-Dialog, ohne UI-Hinweis, ohne Opt-out. Wer die Datei löscht, bekommt sie beim nächsten geeigneten Zeitfenster wieder. Hanff hat das mit einem fabrikneuen Profil auf Apple Silicon nachgestellt, das null menschliche Eingaben gesehen hat – das macOS-eigene .fseventsd-Log zeigt minutengenau: Verzeichnis-Anlage, drei parallele Unpacker-Prozesse, finaler Move – Gesamtdauer 14 Minuten 28 Sekunden, alles im Chrome-eigenen Prozesskontext, nicht via GoogleUpdater.

Pikant ist die parallele „AI Mode“-Pille in der Omnibox: Sie erweckt den Eindruck on-device-Verarbeitung, schickt Anfragen aber an Googles Server. Das lokale Modell wird vom sichtbaren AI-Surface gar nicht aufgerufen – nur von versteckten Features wie „Help me write“ in Textareas. Die User zahlen also Disk und Bandbreite, ohne Datenschutznutzen.

Hanff sieht darin einen direkten Verstoß gegen Art. 5(3) ePrivacy-Richtlinie (Speichern von Informationen auf Endgeräten ohne Einwilligung) sowie gegen Art. 5(1) und Art. 25 DSGVO. Ergänzend rechnet er die Klimakosten durch: bei 0,06 kWh/GB Übertragung und EU-Mix ergibt eine einmalige Auslieferung 0,06 kg CO2e pro Gerät. Bei 100 Millionen bis 1 Milliarde betroffenen Geräten landet man bei 6.000 bis 60.000 Tonnen CO2e – nur für den initialen Push, ohne Re-Downloads, Updates oder die rund 640.000 Tonnen embodied carbon der NAND-Speicher.

Hanff hatte zwei Wochen zuvor bereits Anthropics Claude-Desktop dafür kritisiert, ungefragt Native-Messaging-Bridges in sieben Chromium-Browser zu schreiben. Das Muster ist identisch: Endgeräte werden zur Deployment-Fläche umgewidmet, Consent zur lästigen Formalität. Wer das noch unter „digitale Souveränität“ verbucht, hat den Begriff nie ernst gemeint.

Google Chrome silently installs a 4 GB AI model on your device without consent.

---

.de offline: DNSSEC-Signatur der TLD bricht

Wer am Abend des 5. Mai versuchte, eine .de-Domain aufzulösen, bekam regelmäßig nur ein NXDOMAIN zurück. Jan Mahn dokumentiert auf heise online, wie ab etwa 21:50 Uhr Apps der Deutschen Bahn streikten, Mailclients spinnten und Browser-Fehler aufploppten – unabhängig von Provider und DNS-Resolver. Cache-Hits funktionierten noch eine Weile, neue Lookups nicht.

Die Ursache lag in der DNSSEC-Signatur der .de-Zone selbst. Ein dig @8.8.8.8 de. lieferte den unmissverständlichen Hinweis „RRSIG with malformed signature found for de/soa (keytag=33834)“. Damit war der SOA-Record der gesamten TLD ungültig signiert – jeder DNSSEC-validierende Resolver weltweit verwarf folgerichtig die Antwort. Genau hier wird die Stärke von DNSSEC zur Falle: Die Validierung ist binär. Entweder die Signatur passt, oder die Domain existiert für validierende Resolver schlicht nicht.

DENIC veröffentlichte um 22:55 Uhr eine „Partial Service Disruption“, später die Einschränkung, es seien nur DNSSEC-signierte .de-Domains betroffen. heise widerspricht dem auf Basis eigener Beobachtungen. Cloudflare zog die Notbremse und deaktivierte die DNSSEC-Validierung für .de per RFC 7646 – pragmatisch, sicherheitstechnisch unschön. In der Nacht auf Mittwoch erneuerte DENIC die Zonensignatur, die Ursache des Fehlers ist bislang nicht öffentlich.

Als Sofort-Workaround empfahl heise nicht-validierende Resolver wie 4.2.2.1 oder Quad9 unter 9.9.9.10. Für Betreiber mit eigenem Caching-Resolver (Unbound, BIND) bleibt die Erinnerung: Ein zentraler Single Point of Failure auf Registry-Ebene betrifft eben auch jeden, der lokal valide arbeitet. Cloudflare hatte die Validierung temporär deaktiviert gehabt.

Das Monitoring hier hat jedenfalls ordentlich gescheppert – ich hoffe du bist gut da durch gekommen – keine Sorge, waren ja viele anderen auch betroffen.

DNS-Probleme: .de-Domains nicht erreichbar

---

Building for the future: Cloudflare entlässt 1.100 Mitarbeitende

Mit dem zynisch klingenden Blogpost „Building for the future“ verkündeten Matthew Prince und Michelle Zatlyn diese Woche die Entlassung von 1.100 Mitarbeitenden – rund 20 % der Belegschaft. Die Begründung im Memo ist bemerkenswert offen: Die interne KI-Nutzung sei in den letzten drei Monaten um 600 % gestiegen, Mitarbeitende fahren täglich tausende Agenten-Sessions, und entsprechend müsse man das Unternehmen für die „agentische KI-Ära“ neu aufstellen.

Im Earnings Call wurde Prince noch deutlicher: Support-Rollen rund um Engineering und Sales seien nicht mehr die, „die Unternehmen künftig vorantreiben“. Wall Street honorierte die Klarheit mit einem Kursrutsch von 18 %, trotz starkem Q1. Die Severance-Pakete sind branchenweit überdurchschnittlich: Grundgehalt bis Ende 2026, Equity-Vesting bis 15. August, Cliff-Waiver für Neueingestellte.

Auf Hacker News fasst Nutzer AloysB die Stimmung pointiert zusammen: Im September 2025 stellte Cloudflare 1.111 Praktikanten ein, um „die Zukunft mitzugestalten“ – acht Monate später entlässt man 1.100 Personen, um „weiter an der Zukunft zu bauen“. Cloudflare bricht damit sichtbar ein Tabu, das Meta, Oracle und Microsoft 2026 noch hinter Floskeln wie „efficiency“ und „reorganization“ versteckt hatten.

Passend dazu aus Köln: DeepL-CEO Jarek Kutylowski verkündete am gleichen Tag auf LinkedIn die Entlassung von 250 Mitarbeitenden – ebenfalls rund ein Viertel der über 1.000-köpfigen Belegschaft. Auch hier identische Argumentation: kleinere Teams, KI übernimmt Routineaufgaben, Menschen sollen sich auf das konzentrieren, „was nur Menschen leisten können“. Kutylowski selbst werde eine Arbeitsgruppe leiten, die Produktentwicklung und Vertrieb „mit KI im Mittelpunkt“ neu denkt. Dass das deutsche Vorzeige-KI-Unicorn ausgerechnet eigene Mitarbeitende durch eigene Agenten ersetzt, hat eine eigene Logik – pikant ist sie trotzdem, kurz vor dem zuletzt diskutierten US-Börsengang.

Building for the future

---

Bluesky-Outage: Wenn Ports zur Mangelware werden

Bluesky war Anfang April rund acht Stunden für etwa die Hälfte der Nutzer nicht erreichbar. Engineer Jim Calabro hat in einem öffentlichen Postmortem die Details aufgeschrieben, Lorin Hochstein ergänzt das mit einer lehrbuchreifen Analyse der Failure Modes.

Auslöser war ein neuer interner Service, der gegen den Data-Plane-Endpoint GetPostRecord Batches mit bis zu 20.000 URIs schickte – bei lediglich 3 Requests pro Sekunde. Genau dieser eine Endpoint hatte in Go als einziger keine errgroup.SetLimit-Begrenzung, sodass pro Request 15-20k Goroutinen jeweils eine eigene memcached-Verbindung öffneten. Hier liegt ein verbreitetes Missverständnis: Der eingesetzte gomemcache-Pool ist kein klassischer Connection Pool, der gleichzeitige Verbindungen begrenzt, sondern hält lediglich bis zu 1.000 Idle-Verbindungen zur Wiederverwendung. Bei 15k parallelen Anfragen werden 14k neue Connections aufgemacht, die nach Close() für rund 60 Sekunden im TIME_WAIT-State verharren und den ephemeren Port blockieren. Ergebnis: vollständige Erschöpfung des Port-Ranges (Default 32768–60999, also nur ~28k Slots).

Am Montag eskalierte das in eine Death Spiral: Jeder memcached-Fehler wurde via blockierendem write(2) synchron geloggt, Go spawnte massenhaft OS-Threads, GC-Pausen explodierten, OOM-Kills folgten – und nach jedem Restart blockierte TIME_WAIT die gleichen Ports erneut.

Die Diagnose war entsprechend mühsam. Bluesky hatte zwischenzeitlich auf der Status-Page einen 3rd-Party-Provider als Ursache angegeben – Traceroutes zeigten Paketverluste, die mit dem eigentlichen Problem nichts zu tun hatten. Calabros eigene Lehre: mehr Per-Client-Observability und Metriken statt synchroner Logs.

Der Workaround ist hübsch unsauber: Calabro nutzt aus, dass unter Linux das gesamte 127.0.0.0/8-Netz auf Loopback geroutet wird, und randomisiert pro Verbindung die Source-IP. Da nicht der Port limitiert, sondern das Tupel (IP, Port), vervielfacht sich der nutzbare Raum um Größenordnungen. Hochstein ordnet das mit David Woods‘ „Messy 9″ ein – Saturation, Cascade, Lag in Reinform.

Tja, hatte neulich ein ähnliches Problem, witzigerweise auch mit Memcached – haben dann erstmal auf Socket Connections umgestellt und ein sauberes Monitoring der Port Usage eingeführt, super hilfreich!

April 2026 Outage Post-Mortem

---

Schmunzelecke

„Frontend is ready but backend still in development“ – bei Instagram

---

💡 Link Tipps aus der Open Source Welt

Vosk – Offline Speech Recognition Toolkit

Vosk ist ein Open-Source Speech-to-Text Toolkit, das komplett offline arbeitet und über 20 Sprachen unterstützt – darunter Deutsch, Englisch, Französisch, Spanisch, Chinesisch, Russisch und viele mehr. Von Raspberry Pi bis Server-Cluster skalierbar.

Key Features:

• Komplett offline: Keine Cloud, keine API Keys – alle Verarbeitung lokal
• 20+ Sprachen: Englisch, Deutsch, Französisch, Spanisch, Chinesisch, Russisch, Türkisch, Arabisch, Japanisch, Hindi u.v.m.
• Kleine Modelle: Ab 50 MB, trotzdem kontinuierliche Transkription mit großem Vokabular
• Streaming API: Zero-Latency Response, rekonfigurierbares Vokabular
• Speaker Identification: Sprechererkennung integriert
• Breite Sprachunterstützung: Python, Java, Node.js, C#, C++, Go, Rust, Ruby, Kotlin, Android, iOS
• Skalierung: Vom Raspberry Pi/Android-Smartphone bis zum GPU-Cluster (Batch API für Go)

Vosk ist eines der etabliertesten Open-Source-STT-Projekte und nach wie vor die Go-to-Lösung, wenn Offline-Fähigkeit und Datenschutz Priorität haben. Vergleich zum letzte Woche vorgestellten Handy: Handy ist eine fertige Desktop-App mit GUI, Vosk ist ein Toolkit/API zum Einbauen in eigene Anwendungen.

Und ja, man könnte damit einen lokalen Meeting-Transkriptions-Agent bauen, der Audio vom Mikrofon (oder einem Konferenz-System) in Echtzeit transkribiert – komplett on-premise, ohne dass Gesprächsinhalte an Cloud-Dienste fließen. Die Speaker Identification hilft beim Zuordnen von Sprechern. Für einen vollständigen Meeting Agent müsste man noch ein LLM für Zusammenfassungen und Action Items draufsetzen (z.B. via Ollama lokal) und die Streaming API an den Audio-Input anbinden. Die Python- und Node.js-Bindings machen das Prototyping recht einfach. Für deutsche Meetings gibt es ein dediziertes Sprachmodell.

https://github.com/alphacep/vosk-api

LocalSend – Open Source AirDrop Alternative für alle Plattformen

LocalSend ist eine kostenlose, quelloffene App zum sicheren Teilen von Dateien und Nachrichten zwischen Geräten im lokalen Netzwerk – ohne Internet, ohne Cloud, ohne Drittanbieter-Server.

Key Features:

• Cross-Platform: Android, iOS, macOS, Windows, Linux – alle Geräte können untereinander Dateien austauschen
• Kein Internet nötig: Kommunikation läuft komplett über das lokale Netzwerk via REST API mit HTTPS-Verschlüsselung
• Zero Config: TLS-Zertifikate werden on-the-fly auf jedem Gerät generiert, Geräte finden sich automatisch im Netzwerk
• Kein Account, kein Server: Direkte Peer-to-Peer-Übertragung zwischen den Geräten
• Portable Mode: Settings-Datei neben dem Binary ablegen, App startet ohne Installation
• Hidden Start: Per --hidden Flag nur im Tray starten – ideal für Autostart-Setups

Verfügbar über praktisch jeden Paketmanager und App Store: Play Store, App Store, F-Droid, Flathub, Snap, Winget, Scoop, Chocolatey, Homebrew und mehr.

Mit 80k Stars eines der erfolgreichsten Open-Source-Projekte überhaupt – und das zurecht. LocalSend löst ein alltägliches Problem elegant: Dateien zwischen Geräten verschiedener Ökosysteme teilen, ohne sich mit Cloud-Diensten, Bluetooth-Pairing oder USB-Kabeln herumzuschlagen. Funktioniert einfach. Wer AirDrop vermisst, sobald ein Windows- oder Android-Gerät im Spiel ist, braucht genau das.

https://github.com/localsend/localsend

❓ 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: