Willkommen zu allesnurgecloud.com – Ausgabe #199
Bei uns in Baden-Württemberg haben jetzt die Ferien begonnen und ich verabschiede mich bald in den Urlaub. Ich glaube, 1,2 Ausgaben gibt es noch, und dann ist hier auch erstmal Sommerpause.
In der nächsten Woche ist hier schon Ausgabe 200 am Start – mittlerweile ist da eine Menge Content zusammengekommen.
Falls du mir also zum Jubiläum einen Gefallen tun möchtest – empfehle den Newsletter gerne weiter, das würde mir sehr helfen – also jetzt gleich die Mail weiterleiten – zack zack! Falls du zur Ausgabe 200 was verlosen möchtest, gerne auch einfach per E-Mail Antworten.
Happy Bootstrapping Podcast
In dieser Woche habe ich mit Farina Schurzfeld von AndRobin gesprochen. Farina war für Rocket Internet in Australien und hat dort Groupon aufgebaut, dann hat sie in Australien Airtasker aufgebaut und an die Börse gebracht – zurück in Deutschland hat sie SelfAPY gegründet und verkauft und mit ihrem neuen Baby AndRobin hilft sie Unternehmen bei der Skalierung von Geschäftsmodellen – diesmal aber komplett bootstrapped – Folge 132 jetzt anhören (Spotify/Apple).
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 und der Cloud Act: „Riesenwiesel“ schreibt Blogpost
Bob Kimball von AWS versucht uns zu beruhigen: Der CLOUD Act sei gar nicht so schlimm, wie alle denken. Seit 2020 haben sie angeblich keine Unternehmens- oder Regierungsdaten außerhalb der USA an die US-Regierung weitergegeben. Klingt beruhigend? Moment mal…
Die Fakten laut AWS:
- Der CLOUD Act gibt der US-Regierung keinen automatischen Zugriff auf Cloud-Daten
- AWS hat strenge Verfahren zum Schutz von Kundendaten
- Das Gesetz gilt für alle Anbieter mit US-Geschäftstätigkeit, nicht nur US-Firmen
- Die Prinzipien entsprechen internationalem Recht
- AWS Nitro System und Verschlüsselung schützen vor unbefugtem Zugriff
Corey Quinn riecht Bullshit
Der Cloud-Kritiker Corey Quinn zerpflückt in Ausgabe 433 von „Last Week in AWS“ die AWS-Aussagen genüsslich: „AWS is being very careful about what they’re saying and what they’re not saying—and it stinks of bullshit.“ – AWS wählt seine Worte sehr sorgfältig und das riecht nach Täuschung.
Seine Hauptkritikpunkte:
- AWS spricht nur von „enterprise or government customer content data stored outside the US“ – was ist mit kleineren Firmen, Daten in den USA oder Metadaten?
- Die technischen Schutzmaßnahmen umgehen die eigentliche Frage: „If Andy Jassy walks into the room and demands Customer X’s data, will you give it to him?“ – würde AWS dem CEO die Daten aushändigen?
- Die Statistik ist so eng gefasst, dass sie fast bedeutungslos ist – „It’s like saying ‚we’ve never sold red cars on Tuesdays'“ – technisch korrekt, aber verdächtig spezifisch
Quinn vergleicht das Ganze mit dem prähistorischen Riesenwiesel Megalictis – einem 90 Kilo schweren Marder, der vor 18 Millionen Jahren ausgestorben sein soll. Seine Pointe: „It turns out that the giant weasel did not in fact go extinct, but is instead alive and well at AWS writing blog posts like this one.“ – Das Riesenwiesel lebt noch bei AWS und schreibt solche verschleiernden Blogposts.
Der CLOUD Act bleibt ein heikles Thema. AWS betont Transparenz und Schutzmaßnahmen, während Kritiker die vorsichtige Wortwahl und eng gefassten Statistiken bemängeln. Vertrauen ist gut, Kontrolle und eigene Verschlüsselung sind besser.
Five facts about how the CLOUD Act actually works
Oxide Computer sammelt 100 Millionen Dollar ein
Bryan Cantrill und Steve Tuck berichten über ihre frische 100 Millionen Dollar Series B Finanzierungsrunde – angeführt vom neuen strategischen Partner USIT. Die Summe ist beeindruckend: In den fast sechs Jahren seit Gründung hatte Oxide bisher nur 89 Millionen eingesammelt – diese Runde verdoppelt das Gesamtkapital mehr als.
Über Oxide hatte ich hier schon mehrfach berichtet (Ausgabe #21, #121 und #147) – das Unternehmen baut komplette Cloud-Computing-Racks mit integrierter Hardware und Software. Ein Rack kann bis zu 2048 CPU Cores, 32TB Memory und 1 PB Storage fassen – alles bei 33% weniger Platzbedarf.
Die Vision von 2019 klang verrückt
Die Gründer erinnern sich an die schwierigen Anfänge: „We know you can build this“, sagten viele VCs damals – „but we don’t think that there is a market.“ Die Oxide-Gründer sahen das genau umgekehrt: Die technische Herausforderung war enorm, aber der Markt für moderne On-Premises-Cloud-Lösungen definitiv vorhanden.
Was sie alles selbst gebaut haben:
- Eigene Board-Designs mit Hardware-Root-of-Trust
- Eigenes Microcontroller-Betriebssystem
- Eigenen Hypervisor (keine teuren VMware-Lizenzen!)
- Eigenen Switch mit eigenem Runtime
- Eigenen Storage-Service
- Eigene Control Plane für API-gesteuerte Services
Vor zwei Jahren wurde das erste System ausgeliefert. Der Erfolg kam schneller als erwartet – Kunden wurden zu Podcast-Hörern, lasen die öffentlichen RFDs oder stöberten im Open-Source-Code. Die Transparenz verkürzte die Enterprise-Sales-Cycles erheblich.
Mit USIT und Gründer Thomas Tull fand Oxide einen Investor, der die langfristige Vision teilt. Die 100 Millionen ermöglichen es nun, die drängendsten Kundenfragen zu beantworten: Skalierung in der Fertigung, größere Systeminstallationen und erweiterte Roadmap.
Oxide bleibt seiner Mission treu: „Kick butt, have fun, not cheat, love our customers — and change computing forever.“
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)
Incident Learings bei Heroku, Google Cloud und Neon
Gergely Orosz analysiert die jüngsten Infrastruktur-Ausfälle großer Anbieter. Die Lehren daraus sind teilweise erschreckend – besonders wenn sich Geschichte wiederholt.
Heroku: 23 Stunden Totalausfall durch Ubuntu-Update
Was passiert, wenn Zuverlässigkeit nicht mehr oberste Priorität hat? Heroku lieferte im Juni ein Paradebeispiel:
- 8 Stunden bis zur öffentlichen Bestätigung des globalen Ausfalls
- 11 Stunden bis zur Problemidentifikation
- 23 Stunden bis zur Behebung
- 5 Tage für ein nichtssagendes Postmortem
Der Schuldige: Ein automatisches Ubuntu 22.04 Update, das systemd neu startete und dabei alle Netzwerk-Routen löschte. Exakt dasselbe Problem hatte DataDog 2023 – mit 5 Millionen Dollar Schaden.
Das Erschreckende: DataDog hatte damals ausführlich dokumentiert, was schiefging. Heroku hätte lernen können, tat es aber offenbar nicht. Während DataDog sofort automatische Updates abschaltete, ließ Heroku dieselbe Zeitbombe ticken.
Google Cloud: Config-Replikation legt weltweit Services lahm
Am 12. Juni erwischte es Google Cloud für bis zu 3 Stunden global. Eine fehlerhafte Konfiguration wurde weltweit repliziert – ein Klassiker. Google lernte daraus: „Fail open“ statt „fail closed“ hätte den Impact reduziert, Feature Flags hätten die Ausfalldauer um zwei Drittel verkürzt.
Neon: Wenn PostgreSQL-Experten über PostgreSQL stolpern
Selbst die Serverless-PostgreSQL-Spezialisten von Neon sind nicht immun gegen typische Postgres-Probleme bei Scale: Query Plan Drift und langsame Vacuum-Prozesse. Ein Reminder, dass Datenbanken mit Millionen Rows jeden überraschen können.
Was lernen wir daraus?
- Automatische Updates sind russisches Roulette – besonders für systemd
- Status-Seiten müssen unabhängig laufen – sonst sind sie nutzlos
- Aus fremden Fehlern lernen ist günstiger als eigene zu machen
- Schnelle Kommunikation ist bei Ausfällen essentiell
Heroku wirkt wie ein Unternehmen im Maintenance-Mode – die lahme Reaktion lässt Konkurrenten wie Render, Fly.io und Railway attraktiver erscheinen. Die Parallelen zwischen DataDog 2023 und Heroku 2024 sind ebenfalls beunruhigend. Entweder liest niemand mehr Postmortems, oder man hofft einfach, dass es einen nicht erwischt. Beides keine gute Strategie für kritische Infrastruktur.
Dabei sind gerade Public Postmortems eine hervorragende Quelle für Wissen in diesen Bereichen – und worüber können Newsletter Schreibende wie ich sonst berichten? Mir zeigt es aber mal wieder, dass alle nur mit Wasser kochen. Ich weiß, ich wiederhole mich, aber es hilft.
Why reliability is hard at scale: learnings from infrastructure outages
„Getting Things Done“ in Big Tech
Im aktuellen Blog-Post von Sean Goedecke geht es um eine bittere Wahrheit in großen Tech-Unternehmen: Arbeit ist niemals wirklich „fertig“ – man kann immer noch refactoren, optimieren, features hinzufügen. Die Kunst liege darin zu wissen, wann man aufhören sollte.
Der Gärtner-Vergleich trifft es gut
Software-Entwicklung gleicht eher dem Pflanzen eines Baumes als dem Lösen einer Matheaufgabe. Einmal gepflanzt, braucht der Baum ständige Pflege – genau wie Software. Das Problem: Viele kompetente Entwickler verfangen sich in diesem endlosen Pflegezyklus und liefern marginale Verbesserungen an einem Subsystem, während die Führungsebene sich fragt, warum nichts „Fertiges“ rauskommt.
Wie ich schon in Ausgabe #67 über Scrum bei Big Tech berichtet hatte – bei den großen Tech-Firmen läuft vieles anders. Dort zählt vor allem eins: Sichtbarkeit für die Entscheidungsträger. Ist das nur bei Big Tech so? Ich meine nicht.
Die harte Realität: Was zählt wirklich?
„Getting things done means getting them in a state where: (a) executives at the company understand what’s happened, and (b) are happy with it“ – Goedecke bringt es auf den Punkt.
In Ausgabe #98 hatte ich über den Tech-Mitarbeiter berichtet, der jahrelang angestellt war, aber kaum arbeitete. Das passt perfekt zu Goedeckes Beobachtung über „Task Bloating“ und die Meta-Arbeit durch Agile-Prozesse.
Die Hacker News Community ist gespaltener Meinung und die Reaktionen sind teils heftig. Ein Kommentator bringt es auf den Punkt:
„The trope that ICs are incapable of understanding and balancing business interests against their wishlist of work items is just a cope that incompetent management chains tell themselves“
Ein anderer sieht es pragmatischer:
„If the execs don’t see the value, customers don’t see the value, and you can’t prove money is being made (or saved), where is the value of your work, really? You’re not paid to make art.“
Das Product Manager Dilemma
Besonders interessant ist die Diskussion über Product Manager. Wie ich in Ausgabe #115 über „Glue Work“ beschrieben hatte – diese Koordinationsarbeit ist essentiell, wird aber oft nicht wertgeschätzt. Ein Entwickler berichtet frustriert:
„The day to day work of engineers has become so incredibly specialised and divorced from the needs of decision-makers and the customers that there is almost nothing I can do to influence whether someone views me as doing my job or not.“
Der Artikel trifft einen wunden Punkt. Ja, man muss wissen, wann etwas „gut genug“ ist. Aber die Reduzierung auf „mach die Chefs glücklich“ ist zu kurz gedacht. Die Balance zwischen „Done“ und „Done Right“ bleibt eine Kunst. Wer nur auf kurzfristige Sichtbarkeit optimiert, hinterlässt tickende Zeitbomben. Wer sich im Perfektionismus verliert, wird nie fertig.
Der Schlüssel liegt darin, die richtigen Prioritäten zu setzen – und ja, dazu gehört leider auch, die Sprache der Entscheidungsträger zu sprechen.
Getting things „done“ in large tech companies
CGI ist zurück: 200 Millionen Requests pro Tag mit Gästebuch
Jacob Gold beweist, dass totgesagte Web-Technologien auf moderner Hardware überraschend gut performen. Sein CGI-Gästebuch schafft 2400+ Requests pro Sekunde – genug für 200 Millionen Requests täglich.
CGI-Nostalgie trifft moderne CPUs
Wer in den frühen 2000ern dabei war, erinnert sich: CGI war die Art, dynamische Websites zu bauen. Der Webserver spawnt für jeden Request einen neuen Prozess, übergibt Daten via Environment-Variablen und stdin, sammelt stdout als Response ein. Primitiv, aber genial einfach.
Der große Vorteil damals wie heute: Nach jedem Request stirbt der Prozess – Memory Leaks und offene File Descriptors sind automatisch Geschichte. Das machte selbst grauenhaften Code erstaunlich stabil.
Von 100 auf 384 Threads
Damals: Apache mit 1-2 CPUs und maximal 100 Connections. Ein Link von Slashdot konnte jeden Server in die Knie zwingen.
Heute: Server mit 384 CPU-Threads sind keine Seltenheit. Und CGI-Prozesse nutzen diese vielen Cores exzellent aus – im Gegensatz zu vielen modernen Single-Threaded-Frameworks.
Die Benchmark-Zahlen
Gold testete auf einem älteren AMD 3700X (16 Threads):
- Apache + CGI: 2468 Writes/s, 1959 Reads/s
- Go net/http + CGI: 2742 Writes/s, 2469 Reads/s
- Latenz meist unter 10ms
Sein Gästebuch nutzt Go mit SQLite – pragmatisch und realistisch. Der Code ist auf GitHub verfügbar.
Ein schönes Beispiel dafür, dass „alt“ nicht automatisch „schlecht“ bedeutet. CGI profitiert enorm von modernen Multi-Core-CPUs. Für APIs mit moderatem Traffic könnte das bestimmt eine Alternative zu komplexen Container-Orchestrierungen sein, falls jemand noch weiß, wie das mit dem cgi-bin so funktioniert.
Serving 200 million requests per day with a cgi-bin
Tape ist tot, lang lebe Tape: Zukunft der Langzeitarchivierung
Das c’t Magazin meldet einen neuen Rekord des LTO-Konsortiums (HPE, IBM, Quantum): 176,5 Exabyte an Tape-Medien wurden 2024 ausgeliefert – das vierte Wachstumsjahr in Folge. Klingt beeindruckend? Moment, da ist ein Haken: Diese Zahl basiert auf einer angenommenen Kompressionsrate von 2,5. Die echte Bandkapazität lag bei „nur“ 70,6 Exabyte.
LTO gerät unter Druck
Bruno Hald von Quantum feiert die „Langlebigkeit als führende Speicherlösung“. Doch die Realität sieht anders aus. LTO-10 ist da, aber es kann keine LTO-9-Bänder mehr lesen – ein massives Problem für Archive, die regelmäßig Daten auf neue Generationen migrieren müssen.
Noch schlimmer: Die Preise explodieren. Ein LTO-9-Band kostete noch etwa 100 Euro, LTO-10-Medien werden für 250 Euro und mehr angeboten. Bei 30 TByte Kapazität nähern wir uns gefährlich den Festplattenpreisen – die ersten 30-TB-HDDs kosten rund 600 Euro.
Déjà-vu: Backup-Diskussionen aus der Newsletter-Historie
Wie ich schon in Ausgabe #58 und #109 betont hatte: „S3 ist kein Backup“. Corey Quinn hatte das damals wunderbar auf den Punkt gebracht – man braucht echte Backups gegen versehentliches Löschen, böswillige Angriffe und für schnelle Recovery. Tapes können also weiterhin wichtig sein, selbst in Zeiten von S3 – denn das sichert der Cloud Provider nicht automatisch für mich mit, darum muss ich mich schon selber kümmern.
Die Zukunft der Langzeitarchivierung?
Das LTO-Konsortium kämpft mit der Realität: Für große Datenmengen gibt es aktuell noch keine echten Alternativen. Aber die Arbeiten an neuen Technologien laufen auf Hochtouren – DNA-Speicher und Keramik-Plättchen könnten LTO den Garaus machen.
Die mangelnde Rückwärtskompatibilität von LTO-10 ist ein Sargnagel für viele Archivierungsstrategien. Wer Petabytes an Daten auf LTO-9 hat, steht vor einer teuren Migration oder muss alte Laufwerke vorhalten.
Tape stirbt einen langsamen Tod!?
Die Kostenschere zwischen Tape und Festplatten schließt sich, während Cloud-Storage mit Glacier-Tiers immer attraktiver wird. Für die meisten Unternehmen dürfte sich die Frage stellen: Lohnt sich der Aufwand noch, oder ist es Zeit für einen Wechsel zu moderneren Archivierungslösungen? Aber wie bringe ich dann ein Medium in meinen Bunker Safe?
Tape ist (noch) nicht tot: 2024 wurden LTO-Medien für 176 Exabyte ausgeliefert
SRE-Strategien gegen Alert-Müdigkeit
Jorge Lainfiesta fasst im rootly Blog die Erfahrungen von SREs mit über 100 Jahren Operations-Narben zusammen. Das Ziel: Alerts, die nur bei echten Problemen um 3 Uhr morgens klingeln.
Confidence Streams: Die smarte Alert-Quarantäne
Neue Alerts landen erst in der „Low Confidence“-Warteschleife – hier pingen sie nur in Slack, wecken aber niemanden nachts. Erst nach Bewährung wandern sie manuell in den „High Confidence“-Stream. Ein Praktikum für Alerts, bevor sie Verantwortung übernehmen dürfen.
Customer-First statt CPU-Hysterie
Erfolgreiche Teams fragen nicht „Hat der Container zu viel CPU?“, sondern „Antwortet unsere API schnell genug?“ Der Fokus liegt auf spürbaren Nutzer-Impacts statt internen Metriken – ein Paradigmenwechsel, der sich auszahlt. Hier erinnere ich gerne an meinen Customer Centric Monitoring Vortrag von der OSMC 2024.
Game Days und 40% weniger Noise
Teams simulieren Ausfälle und prüfen, welche Alerts feuern sollten. Oft ernüchternd: Wichtige bleiben stumm, unwichtige kreischen.
Ein Team schaffte 40% Reduktion durch clevere Metadaten-Analyse: Feuert ein Alert an 80% der Tage und löst sich selbst? Weg damit! Ein „Alert Quality Index“ (0-1) identifiziert automatisch die nervigsten Kandidaten.
Der ultimative Reality-Check
Bevor Alerts eskalieren, tragen Entwickler selbst den Pager. Wer 30 Mal pro Woche geweckt wird, überlegt sich zweimal, ob’s wirklich P1 ist. Ein zentraler Incident Manager fungiert als Gate-Keeper. Gute Alerts sind also kein Zufall – sie brauchen Disziplin und kontinuierliche Pflege, damit am Ende die richtigen Leute zur richtigen Zeit geweckt werden.
The Art of Not Getting Woken Up for Nothing
Die 14kB-Regel: Warum deine Website blitzschnell sein könnte
Nathaniel erklärt auf endtimes.dev, warum Websites unter 14kB dramatisch schneller laden. Der Unterschied zwischen 14kB und 15kB kann 612ms betragen – bei 15kB vs. 16kB ist er vernachlässigbar.
TCP Slow Start – Der Performance-Killer
Beim Verbindungsaufbau startet der Server vorsichtig mit nur 10 TCP-Paketen:
- TCP-Paketgröße: 1460 Bytes (nach Abzug der Header)
- 10 Pakete × 1460 Bytes = 14.600 Bytes ≈ 14kB
Passt deine Seite in diese erste Ladung, sparst du einen kompletten Roundtrip.
Latenz-Horror: Satelliten-Internet
Nathaniels Extrembeispiel: Öl-Plattform-Arbeiter mit 612ms Extra-Latenz pro Roundtrip. Mit HTTPS summiert sich das auf 1,8 Sekunden! Aber auch 2G (300-1000ms) oder überlastete Festival-Netze bremsen aus.
Praktische Tipps
- Critical CSS/HTML in die ersten 14kB
- Bilder optimieren oder Platzhalter nutzen
- HTTP-Header zählen mit (unkomprimiert!)
- Mit Kompression werden aus ~50kB Content 14kB
Die 14kB-Regel gilt übrigens auch für HTTP/2 und QUIC.
Wie ich in Ausgabe #73 berichtete, hatte Brad Taunt bereits den 1kB Club für ultrakleine Websites gegründet. Sein minimalistischer CV mit nur 920 Bytes zeigt, was möglich ist – auch wenn er mit Redirect-Tricks etwas schummelt.
Selbst wenn 14kB unrealistisch sind – stelle sicher, dass die ersten 14kB etwas Sinnvolles zeigen. Deine Nutzer auf langsamen Verbindungen danken es dir!
Why your website should be under 14kB in size
Schmunzelecke
Ach, das ist ja herrlich – der Short von letzter Woche war nur ein Ausschnitt aus einem 6 minütigen Interview mit einem Senior DevOps Engineer 2025 – „Hybrid Cloud means signing into AWS with Azure AD“ – herrlich.
💡 Link Tipps aus der Open Source Welt
Cyclops – Kubernetes für alle, ohne YAML-foo
Cyclops ist ein Open-Source-Tool, das Kubernetes durch eine intuitive UI vereinfacht – statt komplexe YAML-Manifeste zu schreiben, konfigurieren und deployen Teams ihre Anwendungen per Mausklick – ClickOps is back! Das Besondere: DevOps-Teams können ohne Code custom UIs für Entwickler, QA-Teams oder Produktmanager erstellen, die keine Kubernetes-Erfahrung haben.
Features:
- Visueller Konfigurator statt YAML-Dateien
- Template-System für wiederverwendbare Konfigurationen
- Eingebaute Validierungen verhindern Fehler
- Nutzt Helm Charts unter der Haube
- Vordefinierte Templates für schnellen Start
- Custom UIs ohne Programmierung erstellen
- Funktioniert mit bestehenden Helm Charts
- Reduziert Konfigurationszeit von Tagen auf Minuten
Endlich macht Kubernetes auch für Nicht-DevOps-Experten Sinn! Cyclops demokratisiert den Zugang zu K8s und beschleunigt Deployments erheblich – ein echter Game-Changer für heterogene Teams.
Cyclops selbst ist Open-Source – für Onboarding und Support kann man sich kostenpflichtige Stunden dazubuchen.
https://github.com/cyclops-ui/cyclops
Copyparty – Ein-Datei-Fileserver mit allem Drum und Dran
Copyparty verwandelt jedes Gerät in einen vollwertigen Fileserver – und das mit nur einer einzigen Python-Datei ohne externe Dependencies! Der Server unterstützt nicht nur HTTP, sondern auch WebDAV, FTP, TFTP und SMB/CIFS, sodass er sich nahtlos in bestehende Workflows integriert.
Features:
- Resumable Uploads/Downloads in jedem Browser
- Multi-Protokoll: HTTP, WebDAV, FTP, TFTP, SMB
- Datei-Deduplizierung und Kompression
- Media-Player mit Equalizer und Playlist-Support
- Thumbnail-Generierung und Grid-Ansicht
- Volltext- und Metadaten-Suche (MP3-Tags etc.)
- Markdown-Viewer mit Live-Streaming von Logfiles
- Android-App und iOS-Shortcuts
- Zeroconf/mDNS für automatische LAN-Erkennung
- Selbstzerstörende Uploads mit Zeitlimit
Die Schweizer Taschenmesser-Lösung für Fileserver! Perfekt für schnelles Filesharing im LAN oder als permanenter Medienserver – alles ohne kompliziertes Setup. Copyparty gibt es in sämtlichen Varianten und für alle möglichen Betriebsysteme – einfach mal hier checken.
Und hier hast du ein paar Screenshots, vom Browser, Uploading oder den Thumbnails.
https://github.com/9001/copyparty
❓ 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: