Bitte ruiniert diese Software nicht mit Vibe
(github.com/RsyncProject)- Dieses Issue endete im Status Closed und war ein eher anklagender Beitrag ohne Reproduktionsschritte oder Vorschläge zur Behebung; entsprechend sind keine verknüpften Branches, PRs oder Meilensteine sichtbar
- Der ursprüngliche Vorwurf war, dass in rsync von KI beeinflusste Änderungen eingeflossen seien und dadurch die Stabilität ins Wanken gerate; der Beitrag selbst bestand weitgehend aus Bildern ohne erklärenden Text
- Ein Nutzer berichtete, dass wegen der Verwendung von rsync in log2ram ein 3D-Drucker mit 100 % CPU-Auslastung lief, und formulierte es so, als habe KI diesen Bug in einen Roboter eingeschleust
- Ein anderer Nutzer meinte, rsync sei ein stabiles Werkzeug, das eher Sicherheitsupdates und Bugfixes als neue Funktionen oder Umschreibungen brauche, und dass in den letzten beiden Patch-Releases Probleme aufgetreten seien, bei denen bestehendes Verhalten nicht hätte verändert werden dürfen
- Ein Nutzer, der rsync für DFIR-Arbeit einsetzt, erklärte, dass allein die Tatsache, dass KI an Updates beteiligt sei, es nach den Richtlinien seiner Organisation bereits zu einem „KI-Tool“ mache und daher zusätzliche Prüfungen nötig würden
- Die Gegenseite hielt dagegen, dass der Issue-Tracker kein Ort für virale Beschwerden sei und dass man ohne konkreten Bug-Report oder Reproduktionsschritte das Thema nach Discussions verschieben oder forken solle
- Der zentrale Konflikt verschärfte sich zwischen der Haltung „Es ist freie Software, also fork es, wenn es dir nicht gefällt“ und der Gegenposition, dass rsync bereits ein kritisches Infrastruktur-Werkzeug sei und schon Diskussionen über Pinning oder Forks bei Downstream-Nutzern ein Warnsignal seien
- Einige Nutzer erwähnten eine Neuschreibung in Rust oder einen Fork, andere entgegneten jedoch, dass rsync gerade wegen seiner Stabilität und seines unveränderten Verhaltens geschätzt werde und eine Neuschreibung ein separates Projekt sei
- Befürworter des KI-Einsatzes argumentierten, man dürfe nicht jede Erwähnung von KI pauschal als „Vibe Slop“ abtun, sondern müsse die Commit-Logs seit März direkt auditieren, um die Gründe für die Änderungen zu prüfen
- kaithar erklärte, die jüngsten Arbeiten umfassten Bug- und Sicherheitsbehebungen sowie Härtung, darunter das Lesen nicht initialisierten Speichers, Over-/Underflows im Wire-Protokoll, 32-Bit-Zeitstempel und Anpassungen im Zusammenhang mit dem C-Standard
- Im selben Kommentar wurde entgegnet, dass ein Festhalten an älteren Releases wie 3.4.1 dazu führen könne, auf Versionen mit mehreren CVEs sitzenzubleiben, und dass Regressionen durch Edge Cases entstehen könnten, die von Tests nicht abgedeckt wurden
- Letztlich lief das Issue nicht auf eine konkrete Fehlerbehebung hinaus, sondern blieb als Debatte darüber bestehen, wie man in langfristig stabiler Infrastruktur wie rsync mit Vertrauen, Auditierbarkeit und Governance bei KI-gestützter Entwicklung umgehen sollte
1 Kommentare
Hacker-News-Kommentare
Dieses Rudelmobbing ist wirklich bizarr, und einige scheinen sich irrational zu verhalten. Ich kann bis zu einem gewissen Grad verstehen, warum man diesen Kampf „gewinnen“ will, aber so ganz sicher nicht, und am Ende wirkt es nur wie fanatisches Verhalten
Es reicht, auf der Issue-Seite nach regression zu suchen und in fünf Minuten 17 Ergebnisse zu überfliegen. Im Tracker von vor GitHub könnte es noch mehr geben
Dieses Verhalten ist sehr töricht, und es wirkt, als würden sich die Leute an allem festklammern, um AI-Hass zu rechtfertigen. Als hätten sie vergessen, dass Menschen auch schon vor AI Fehler gemacht haben
Wenn es Belege dafür gibt, dass AI die Zahl der ungelösten Issues in rsync spürbar erhöht hat, würde ich die gern sehen. Dann ändere ich meine Meinung gern
Es muss nicht die direkte Ursache dieses Commits sein, kann aber eine Reaktion auf andere aufgelaufene Probleme sein, und das sollte für sich genommen berücksichtigt werden
Es wirkt, als seien die Leute es leid, Geschichten der Art „AI ist das Beste seit [kulturelle Metapher]“ zwanghaft schlucken zu müssen, und wollten nun nach jedem Strohhalm greifen, um sich dagegen zu wehren; ich halte das für eine ziemlich normale Reaktion
Wenn niemand die Sorge ausspricht, dass Nutzer AI nicht vertrauen, wie soll der Maintainer das dann erfahren? rsync war sehr stabil. Sollen die Leute still zu Openrsync wechseln und nichts dazu sagen?
Einer der Links dort führt zu einer größeren Sammlung von Bugs, die in nachgelagerten Distributionen gemeldet wurden (https://github.com/void-linux/void-packages/issues/60825)
Wenn man den Ruf von Vibecoding-Software bedenkt, ist die Empörung sehr vernünftig. Sogar Fachleute, die ich schätze, sagen Dinge wie: „Damit man keine Bugs einführt, muss man es auf sehr bestimmte Weise handhaben, und wahrscheinlich sollte man es nur für Version 0 zum Ausloten einer Domäne verwenden“
Und hier zieht ein Maintainer den Nutzern mit der Absicht, „mehr Funktionen hinzuzufügen“, auf offenkundig unsichere Weise den Teppich unter den Füßen weg — bei einem zentralen Backup-Werkzeug, das Industriestandard ist
Im Timeshift-Thread steht auch, dass nach einem rsync-Update die CPU-Auslastung während täglicher Backups so stark anstieg, dass man Timeshift stoppen musste, weil es scheinbar endlos lief
Anders gesagt: Die Leute sind frustriert und wütend, weil ein Tool, dem sie ihre Backups und ihre Daten anvertraut haben, mit einer enormen Zahl von Regressionen und neuen Bugs ihre gesamte Backup-Infrastruktur beschädigt, und der Grund dafür ist, dass der Kernentwickler Vibecoding betreibt
Sogar Vibecoding-Experten wie Simon Willison sagen ausdrücklich, dass das nur „wenn man das Tool auf eine bestimmte Weise handhabt“ möglich ist; entweder tut dieser Maintainer das nicht, oder die Aussage stimmt nicht
Wenn man den betreffenden Thread tatsächlich liest und nicht nur die Stellen überfliegt, an denen die beiden sich streiten, gibt es mehrere Berichte, dass Nutzer in Industrie- und Regierungsumgebungen den gesamten Prozess erneut durchlaufen müssen, um diese Software zu aktualisieren. Die Software ist sofort nicht mehr vertrauenswürdig geworden, hat den Nutzern direkt geschadet und den eigentlichen Daseinszweck der Software untergraben
Ich wäre wohl auch wütend, wenn ich diesem Tool mehr als 500 GB an Backups anvertraut hätte, und würde mich fragen, wie viele weitere Probleme hineingeraten sind, die erst auffallen, wenn eine Firma ihre Backups nicht regelmäßig testet und dann einen Datenverlust in Höhe von 10 Millionen Dollar erleidet
Ich verstehe das wirklich nicht
Es gibt robuste Software, die von unzähligen Menschen und Diensten genutzt wird. Sie funktioniert gut, erfüllt ihren Zweck und braucht höchstens gelegentlich kleine Bugfix-Updates
Wozu braucht es hier AI?
Außerdem verstehe ich nicht, warum Leute sagen: „Forkt es und nutzt die ältere Version.“ Es sollte eher genau andersherum sein. Man sollte einen parallelen Fork wie younamethetool-ai erstellen und das Original unangetastet lassen
Muss ich jetzt mein gesamtes System-Tooling forken und pflegen?
Zur Frage „Warum braucht es hier AI?“: Wie auch in mehreren Issue-Kommentaren gesagt wird, ist es Sache der Entwickler, die zu einem Open-Source-Paket beitragen, zu entscheiden, wie sie arbeiten
Sich ohne Belege im Issue-Tracker darüber zu beschweren, dass AI die Software ruiniert, ist eine Form von Belästigung von Open-Source-Mitwirkenden, die auf Hacker News häufig diskutiert wird [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
„Ein Issue-Tracker ist kein Ort, um virale Social-Media-Posts abzugreifen. Melde einen umsetzbaren Bug oder fork es selbst. Sich über Entscheidungen von Entwicklern auszulassen, ist nicht produktiv“
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
„@II-Paulus-II hör auf. Du weißt gar nichts. Du hast per Hand null Features ausgeliefert. Niemand ist von deinem Code abhängig. Du bist nur jemand, der mit dem Finger auf ‚AI hat das geschrieben‘ zeigt und sich hinter einer moralischen Überlegenheit versteckt, weil er Spielzeugprojekte und Skripte von Grund auf selbst schreibt. Du kannst nicht shippen, du kannst dich nicht anpassen, und du verstehst nicht einmal, dass ein Issue-Tracker nicht der Ort für so ein Verhalten ist“
[1] https://news.ycombinator.com/item?id=43077833
Dem Gefühl „Bitte ruiniert dieses stabile und verlässliche Arbeitstier nicht“ stimme ich zu 100 % zu
Ich habe es nicht im Detail gelesen, aber der Satz „In diesem Release wurden 6 CVEs behoben. Alle sechs wurden von VulnCheck als CNA zugewiesen. Betroffene Versionen sind in allen Fällen 3.4.2 oder älter“ wirkt wie eine ziemlich starke Antwort auf das „Warum?“
https://download.samba.org/pub/rsync/NEWS#3.4.3
Es ist bedauerlich, wie viel Anspruchsdenken viele Open-Source-Entwickler ertragen müssen. Man muss sich nur vorstellen, man baut in seiner Freizeit kostenlos etwas und muss sich dann mit einer wütenden Menge auseinandersetzen, die nie einen Cent bezahlt hat und sich nun darüber aufregt, dass man etwas getan hat, das ihr nicht gefällt
Die erste Reaktion wäre natürlich wohl, ihnen zu sagen, sie sollen sich verziehen
Ist das nicht Sache der Maintainer? Wenn sie entscheiden, mit AI mehr Tests zu schreiben, dann sollen sie das tun. Sie schulden der Öffentlichkeit nichts
Wenn die „Öffentlichkeit“ das Projekt übernehmen und pflegen will, kann sie es forken, aber das ist ein undankbarer Job
Warum sollte ein Maintainer sein eigenes Repository selbst forken? Das ergibt keinen Sinn. Wer soll denn dann das alte Repository pflegen?
Außerdem braucht man bei einem Open-Source-Projekt keinen Grund, um zu ändern, welche Tools man verwendet, und man schuldet dir diesen Grund auch nicht
Die Art, wie dieses Issue eröffnet wurde, ist wirklich unerquicklich, aber ich verstehe auch nicht, warum die Maintainer offenbar AI auf rsync losgelassen haben. Warum? Wenn man bereits Ansehen und Vertrauen gewonnen hat, in einer bestimmten Nische führend ist, keinem Marktdruck ausgesetzt ist, die Leute das Tool mögen und es genau das tut, was es soll — warum versucht man dann vergleichsweise experimentellen Krimskrams?
Das wirkt wie dieser kurze Monolog in Matrix, dass der primitive menschliche Geist das Paradies nicht annehmen kann. Man hatte ein perfektes Tool, man hat gewonnen, in der Nische ist es fast unersetzlich, verlässlich und bildlich gesprochen ein Name, den jeder kennt. Daran herumzuspielen oder damit zu pokern ergibt für niemanden Sinn und ist wirklich verwirrend.
Trotzdem ist so etwas im offiziellen Issue-Tracker weiterhin ein wirklich unangenehmes Verhalten. Der Ton ist schlecht und guter Wille ist auch nicht zu erkennen.
Aber inzwischen wirkt AI nirgends mehr eindeutig positiv, und ich sehe diesen Widerstand gegen den Einsatz generativer AI als gute Kurskorrektur der Öffentlichkeit.
Es gibt Texte über die unmittelbare Befriedigung bei der Nutzung von LLMs, und je mehr ich mit Leuten zu tun habe, die diese Tools verwenden, desto mehr denke ich, dass das wirklich der Kern des Problems sein könnte. Unsere Biologie kommt damit nicht klar.
Eigentlich sehe ich hochintelligente Menschen, die wirklich dumme Dinge tun, nur weil es ihnen eine Slotmaschine gesagt hat, und die sogar dahin trainiert wurden, hilflos zu werden, wenn die Slotmaschine versagt.
Ich gelte dann als Luddite, der keinen Fortschritt erkennt, während Kollegen sinnlose Benchmarks bauen und hübsche, von AI erzeugte Diagramme dranhängen.
Dann muss ich mich entscheiden, entweder zu lächeln und so zu tun, als wäre es gute Arbeit, oder sie dafür zu tadeln, dass ihr Benchmark bedeutungslos ist, weil er einen Bereich testet, der als Konstante fest verdrahtet ist. So oder so behandle ich sie nicht wie kluge Kollegen, sondern wie Siebenjährige.
Wo auf der Skala zwischen perfekten, verantwortungsvollen Maintainern und unfähigen Kindern sich die rsync-Maintainer befinden, wissen wir in Wahrheit nicht.
Aber auf die Gefahr hin, etwas vom Thema abzuweichen, denke ich dabei an Folgendes. Abgesehen davon, dass reife Software wie Rsync keine Aktivität nach Maßgabe geänderter Codezeilen braucht, nehmen wir einmal an, die Maintainer verwalten das Projekt mit den besten Absichten.
Wenn so etwas im Open Source passiert, in welchem Zustand ist dann die Qualität proprietärer Software?
Die Menge der AI-Nutzung, also Inputs, fließt als Erfolgskennzahl offenbar in Mitarbeiterbewertungen ein, und die Leute sind wegen der Drohung massenhafter Entlassungen durch AI in Panik.
Schwindelerregend.
https://github.com/RsyncProject/rsync/issues/929#issuecommen... zeigt, dass es auf älteren Darwin-Versionen und Linux < 5.6 nicht mehr funktioniert, wobei Linux 5.6 bereits 2020 zur Ausmusterung vorgesehen war. Dazu kommen noch ein paar andere Bugs.
Man kann nicht erwarten, dass ein Maintainer alte Systeme unterstützt und sämtliche Auswirkungen einer Änderung kennt — egal ob mit AI oder von Hand.
Übrigens wurde der Bug selbst in 30656c5e eingeführt, das von Claude Code erstellt wurde, vermutlich zusammen mit unzureichendem Review und Testing.
https://github.com/RsyncProject/rsync/commit/30656c5e
Jemand hat mit AI ein Bisecting des jüngsten rsync gemacht: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
Jemand versucht, es mit noch mehr Claude Code zu reparieren: https://github.com/RsyncProject/rsync/pull/930
Zugehöriges Ticket: https://github.com/RsyncProject/rsync/issues/915
Ich würde empfehlen, im Commit direkt vor 30656c5e zusätzliche Regressionstests hinzuzufügen und dann unter Beibehaltung der Funktionalität darauf aufbauend nach vorn zu rebased.
Das war keine „unerwünschte neue Funktion“. Tridge arbeitete an der Behebung eines Sicherheitsproblems im Zusammenhang mit einem Bugreport. Verständlich — wir alle bekommen Sicherheitsprobleme um die Ohren gehauen. Sie zu beheben ist keine Option, sondern Pflicht.
Ich würde nicht behaupten, dass es Spaß macht, dafür in zehn Jahre alte Software zurückzugehen, und gerade deshalb finde ich es beeindruckend, dass tridge sich darum bemüht.
Ich selbst bin auch schuldig, LLMs zu benutzen, um mich durch solches Chaos zu arbeiten. Ich weiß nicht, was tridge genau macht, aber ich prüfe jede einzelne Zeile Code, die ein LLM ausspuckt. Trotzdem ist das Risiko klar hoch, dass Bugs durchrutschen.
Ich hatte den Code lange nicht mehr vor mir und bin auch nicht mehr so vertraut damit wie früher. Dass Bugs durchrutschen, ist daher keine große Überraschung.
Das Seltsame an diesem Ausbruch ist, dass die Person mit der ursprünglichen Beschwerde ihr Backup-System offenbar sehr stark schützen will, tridges Commit aber gerade einmal zwei Wochen alt war. Ich weiß, dass tridge hervorragend ist, aber sollte man so etwas nicht selbstverständlich wie Alpha-Software behandeln? Was hat die Person sich dabei gedacht? Vielleicht muss sie selbst auch noch ein wenig lernen, wie man ein verlässliches System baut.
Vor ein paar Jahren wäre die Wahrscheinlichkeit, dass so ein Beitrag auf die Hacker-News-Startseite kommt, nahezu null gewesen. Unabhängig davon, ob der Inhalt richtig ist oder nicht, lag das daran, dass es hier nicht voller ganz normaler Leute war, die nicht verstehen, welches Verhalten inakzeptabel ist
Gemeint ist hier die gewalttätige Sprache des Issues. Inzwischen sind wir aber von Leuten umgeben, die nicht einmal das Offensichtlichste auseinanderhalten können
So sagt man Maintainern nicht, dass man mit der Projektrichtung nicht einverstanden ist. Dieses Issue ist völlig nutzlos. Sogar ein Bug-Report im Stil von „kaputtgemacht durch vibe coded“ wäre besser gewesen
Das trifft den Kern. Kein einziger Bug-Report versucht auch nur, die behauptete --compare-dest=-Regression zu dokumentieren. Selbst mit Ctrl-F scheint niemand „compare-dest“ noch einmal erwähnt zu haben
Die Leute, die nutzlose wütende AI-Kommentare posten, hätten stattdessen Opus 4.8 rsync 3.4.3 und 3.4.1 laufen lassen können, um die Regression gründlich zu dokumentieren, und mit git bisect den kaputten Commit zu finden, um einen 1000-mal professionelleren und nützlicheren Bug-Report zu erstellen
Wenn die Gesellschaft menschliche Arbeit höher bewerten soll als AI-Arbeit, dann wäre es gut, dumme Verhaltensweisen zu vermeiden, zu denen nur Menschen fähig sind
Ist es nicht möglich, dass es auf die Startseite kam, weil andere bei Software, die sie täglich für wichtige Arbeit nutzen, ähnlich empfinden?
Das GitHub-Issue ist abgedroschen und offensichtlich eine undankbare Sache, aber realistisch gesehen ist rsync ein Grundpfeiler vieler sensibler Pipelines
Wenn man wirklich glaubt, dass es völlig am Thema vorbeigeht, wäre die höfliche Reaktion, das Issue zu schließen
Ich verstehe immer noch nicht ganz, was daran so offensichtlich sein soll. Für mich wirkt „Hör auf. Du weißt gar nichts. Du hast per Hand null Features ausgeliefert. Niemand ist von deinem Code abhängig“ sehr viel gewalttätiger als „please do not vibe fuckup this software“
Hat in diesem Issue-Thread eigentlich irgendjemand das Problem tatsächlich erklärt? Also Reproduktionsschritte, erwartetes Verhalten und tatsächliches Verhalten?
Das wurde in einen Issue-Tracker eingestellt. „Im Commit-Text wird Claude erwähnt, und irgendwer auf Bluesky glaubt, dass ein nicht näher bestimmtes Problem, das er hatte, mit diesen Commits zusammenhängt“ ist kein bearbeitbares Issue
Wenn man die gesamte übrige Diskussion beiseitelässt: Wäre es mein Projekt, hätte ich es wegen „fehlender Reproduktionsinformationen“ geschlossen und gesperrt. Für allgemeine Debatten über AI, Forks und Wutausbrüche gibt es bessere Orte
Nutzer von Linux < 5.6 können nicht von GitHub aus bauen. Das wirkt auf mich wie eine ziemlich kleine Regression. Wer einen gepflegten 5.6-Zweig nutzt, meist mit erweitertem Security-Support, dürfte Distributions-Maintainer haben, die Build-Fehlschläge bemerken und rechtzeitig beheben können
Eine Härtung gegen Path-Traversal-Angriffe verursacht Fehler bei Nutzern, die das native rsync-Protokoll ohne chroot verwenden. Ironischerweise wird chroot = no ohnehin nicht ausdrücklich empfohlen
Man könnte sogar sagen, dass man natives rsync nicht automatisiert einsetzen sollte, vielleicht überhaupt nicht. Das CVE, das der betreffende Commit behebt, gilt genau für diesen Anwendungsfall
https://www.cve.org/CVERecord?id=CVE-2026-29518
Erforderlich ist ein Daemon + no chroot. „daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.“
Der betroffene Workflow ist also der verwundbarste Workflow, und trotzdem raten Leute dazu, auf eine ältere Version zurückzugehen
Und selbst wenn ein Regressionstest das hätte auffangen sollen, hätte dieser Test vorher schon existieren müssen
Manche scheinen bei FOSS-Projekten etwas vergessen zu haben
„15. Haftungsausschluss
Soweit gesetzlich zulässig, gibt es für dieses Programm keinerlei Gewährleistung. Sofern nicht schriftlich anders angegeben, stellen die Urheberrechtsinhaber und/oder Dritte das Programm ‘wie es ist’ ohne irgendeine Gewährleistung bereit, weder ausdrücklich noch stillschweigend. Dies umfasst insbesondere, aber nicht ausschließlich, stillschweigende Gewährleistungen der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Das gesamte Risiko hinsichtlich Qualität und Leistung des Programms liegt bei Ihnen. Sollte sich das Programm als fehlerhaft erweisen, tragen Sie die Kosten aller erforderlichen Wartungs-, Reparatur- oder Korrekturmaßnahmen selbst“
Ich behalte mir das Recht vor, mich über alle Entscheidungen, Commits, Patches, Marketingmaßnahmen und sonstigen Entscheidungen eines Projekts zu beschweren, zu nörgeln, sie zu kritisieren, mich darüber aufzuregen oder sie anderweitig zu kommentieren. Solche Kommentare garantieren keine Eignung für irgendeinen Zweck und beinhalten auch keine stillschweigende Gewährleistung, richtig, nützlich oder freundlich zu sein. Falls sich meine Kommentare als unerwünscht erweisen, behalten Sie sich das Recht vor, sie dorthin zu stecken, wo keine Sonne hinscheint
Man kann diesen Haftungsausschluss gern ausdrucken und bei unerwünschter Kritik an FOSS-Projekten zur Hand haben
Ich verstehe nicht, warum Leute nicht begreifen, dass die Haltung „sie können tun, was sie wollen“ in beide Richtungen gilt. Nutzer können auch tun, was sie wollen. Wenn es ihnen nicht gefällt, können sie das äußern
Einer der Kommentare in dem Issue sagt dazu
„Nur weil man einem Obdachlosen kostenlose Suppe gibt, heißt das nicht, dass man hineinpinkeln darf“
Das betreffende Issue ist bereits völlig entgleist, und dein Argument wurde dort auch schon gebracht. Alle hätten es besser handhaben können, aber blind juristische Formulierungen zu zitieren löst das Problem nicht und macht es auch nicht besser
Ich lese jetzt zum dritten Mal einen HN-Post zu diesem Thema. Jedes Mal werden nur dieselben Tweets wiederholt, oder dieser eine Post, wie auch immer man so etwas auf Mastodon/Bluesky nennt. Hat das Problem eigentlich irgendjemand tatsächlich debuggt?
Lag die Ursache an schlampig generiertem Code, oder hat ein echtes Security-Fix zufällig etwas kaputtgemacht? Also auf eine Weise, wie es auch Menschen hätten tun können
Diese Anti-AI-Hysterie ist eine typische moralische Panik
Wie bei jeder moralischen Panik ist es völlig zweitrangig, ob Punkt 1 überhaupt stimmt. Entscheidend ist, dass man aus Punkt 2 fast so etwas wie sexuelle Befreiung zieht
In diesem Fall weiß ich, dass es in rsync AI-generierten Code gibt. So wie inzwischen in den meisten nützlichen Softwareprojekten. Aber online sieht man jeden Tag Hexenjagden, und wie bei allen Hexenjagden ist es kaum wichtig, ob die Anschuldigung wahr ist. Die Hysterie selbst ist das Ziel
Die Wut rund um AI ist kein Problem davon, dass die Öffentlichkeit falsch informiert wäre oder die Botschaft falsch ankäme, sondern eines der physischen Realität
Dieses eine Ding wird als Vorwand für Massenentlassungen benutzt, Tech-CEOs sagen fast täglich, dass sie auch noch allen anderen die Jobs wegnehmen werden, und die großen Cloud-Unternehmen saugen den gesamten Sauerstoff aus dem Raum. Nicht einmal die Spielebranche war sicher
Das als „bloß eine typische moralische Panik“ abzutun, ist so, als würde man sehen, in welche Richtung sich das Meer zurückzieht, und genau dorthin losrennen
Beim Weiterlesen sieht man, dass du selbst emotional aufgeladene Wörter wie „Hexenjagd“ und „Hysterie“ benutzt
Ist das wirklich eine Hexenjagd? Und kann man überhaupt wissen, ob Menschen auf der anderen Seite des Internets so etwas wie sexuelle Befreiung empfinden?
Reagierst du damit nicht selbst auf dieselbe Weise auf die emotionale Sprache und das lockere Denken anderer?
Seit wann sind GitHub-Issues ein Ort, um Screenshots von Posts anderer Plattformen hochzuladen?
So ein Verhalten habe ich bisher nur dort gesehen, wo Memes oder Unterhaltungscontent gepostet werden
Kein umsetzbarer Bug-Report, keine Feature-Anfrage. Keine Textversion. Nicht einmal ein Link zum Original-Post
Hat die Person, die das hochgeladen hat, GitHub Issues mit ihrem persönlichen Twitter-Account verwechselt?