どうかこのソフトウェアをバイブコーディングで台無しにしないでください
(github.com/RsyncProject)- この issue は Closed 状態で終了しており、本文に再現手順や修正提案のない問題提起的な投稿であるため、関連するブランチ・PR・マイルストーンは見当たらない
- もともとの問題提起は、rsync に AI が関与した変更 が入ることで安定性が揺らぐのではないかという懸念で、本文はテキストによる説明なしに画像中心で投稿されている
- ユーザーは、log2ram が rsync を使っているため 3D プリンター が 100% CPU で動作したと報告し、AI がこのバグをロボットに持ち込んだようなものだと表現している
- 別のユーザーは、rsync は新機能や再実装よりも セキュリティアップデートとバグ修正 だけを必要とする安定したツールであり、最近の 2 回のパッチリリースでは既存機能を変えるべきではない場面で問題が起きたと見ている
- DFIR 業務で rsync を使うユーザーは、AI が更新に関与しているという事実だけで、組織のポリシー上「AI ツール」として扱われ、追加レビューが必要になったと説明している
- 反対側では、issue tracker は拡散狙いの不満表明の場ではなく、具体的なバグレポートや再現手順がないなら Discussions に移すかフォークすべきだと反論している
- 核心の対立は、「無料ソフトウェアなのだから気に入らなければフォークすればいい」という立場と、rsync はすでに 中核インフラツール であり、ダウンストリームでの pinning・フォークの議論自体が問題の兆候だという立場の間で大きくなっている
- 一部のユーザーは Rust での再実装やフォークに言及したが、別のユーザーは rsync が愛される理由は 安定性とそのまま動くこと にあり、再実装は別プロジェクトの話だと線引きしている
- AI 利用擁護側は、AI への言及をすべて「バイブスロップ」と決めつけるべきではなく、3 月以降のコミットログを自分で監査して変更理由を確認すべきだと求めている
- kaithar は、最近の作業には未初期化メモリの読み取り、ワイヤプロトコルのオーバーフロー/アンダーフロー、32 ビットタイムスタンプ、C 標準に関する調整など、バグ・セキュリティ欠陥の修正とハードニング が含まれていると説明している
- 同じコメントでは、3.4.1 のような古いリリースに固定すると複数の CVE を抱えたバージョンにとどまる可能性があり、回帰はテストで拾えなかったエッジケースで発生しうると反論している
- 結局この issue は具体的なバグ修正には収束せず、rsync のような長期安定インフラにおいて AI 支援開発の信頼・監査・ガバナンス をどう扱うかという論争として残った
1件のコメント
Hacker Newsの意見
この集団的な押しかけ方は本当に奇妙で、一部は非理性的に振る舞っているように見える。この争いで「勝ちたい」と思う動機はある程度理解できるが、こんなやり方はまったく違うし、ただ狂信者のように見えるだけだ。
issueページで regression を検索して17件の結果をざっと見るのに5分もあれば十分だ。GitHub以前に使っていたトラッカーにはもっとあるかもしれない。
こうした振る舞いはとても愚かで、人々は AI嫌悪 を正当化するために使えるものすべてにしがみつこうとしているように見える。AI以前から人はミスをしていたという事実を忘れているようだ。
AIがrsyncの未解決issueを有意に増やしたという証拠があるなら示してほしい。そうなら喜んで考えを改める。
今回のコミットの直接原因ではないかもしれないが、別の蓄積した問題への反応かもしれず、それ自体考慮されるべきだ。
「AIは[文化的比喩]以来最高だ」というような話を無理やり飲み込まされることにうんざりした人たちが、どんな藁にもすがってでも対抗しようとしているように見えるし、それはかなり普通の反応だと思う。
ユーザーが AIを信頼していない という懸念を誰も口にしなければ、メンテナーはどうやって知れるのか？ rsyncは非常に安定していた。人々は黙ってOpenrsyncへ移り、何も言わないべきなのか？
そのうちの1つのリンクは、下位ディストリビューションで報告されたバグをさらに大きく集約した場所につながっている (https://github.com/void-linux/void-packages/issues/60825)
vibecodingソフトウェアの評判を考えれば、怒りは非常に合理的だ。好んでいる専門家たちでさえ、「バグを出さないようにするには非常に特定のやり方で扱う必要があり、おそらくドメインを描いてみるための0番台バージョンにだけ使うのがよい」と言っているレベルだ。
なのに業界標準の バックアップの中核ツール が、「もっと機能を追加する」ことを目指すメンテナーの意向で、明らかに安全でないやり方でユーザーの足元をすくわれている。
Timeshiftのスレッドにも、「rsync更新後、日次バックアップ中のCPU使用量がひどすぎて、timeshiftが永遠に回り続けるのを止めなければならなかった」という内容がある。
言い換えれば、人々がバックアップとデータを任せていたツールが、膨大な数のリグレッションと新たなバグによってバックアップ基盤全体を壊しており、その理由が中核開発者のvibecodingにあるため、失望し怒っているのだ。
Simon Wilsonのようなvibecodingの専門家でさえ、これは「特定のやり方でツールを扱う場合にのみ」可能だと明言しているのに、このメンテナーはそうしていないか、あるいはその話自体が事実ではないことになる。
そのスレッドを実際に読み、2人が言い争っている部分だけを追わなければ、産業や政府環境のユーザーがこのソフトウェアを更新するために全手順をやり直さなければならないという報告が複数ある。ソフトウェアが即座に信頼できないものになってユーザーに直接被害を与え、そのソフトウェアの存在理由を損なってしまったからだ。
私もこのソフトウェアに 500GB超のバックアップ を任せていたなら怒っていただろうし、会社がバックアップを継続的にテストしていなかった結果、1,000万ドル規模のデータ損失を被るまで表面化しない問題が、ほかにどれだけ入り込んでいたのか気になる。
本当に理解できない
大勢の人やサービスが使っている堅牢なソフトウェアがある。ちゃんと動作し、役目を果たし、ときどき些細なバグ修正アップデートがあれば十分だ
ここでなぜAIが必要なのか？
しかも、なぜ人々が「フォークして以前のバージョンを使え」と言うのかも分からない。むしろ逆であるべきだ。younamethetool-ai のような並行フォークを作って、元のものには手を付けるべきではない
これで自分はシステムツール一式を全部フォークして保守しなければならないのか？
根拠もなく issue tracker でAIがソフトウェアを台無しにすると不満を言うのは、Hacker Newsでよく議論されるオープンソース貢献者いじめの一形態だ [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
「issue tracker はバイラルなソーシャルメディア投稿を刈り取る場所ではない。実行可能なバグを報告するか、自分でフォークしろ。開発者の選択について感情をぶちまけるのは建設的ではない」
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
「@II-Paulus-II、やめろ。お前は何も分かっていない。手作業で機能を1つもデプロイしたことがない。お前のコードに依存した人間は誰もいない。お前は、おもちゃのプロジェクトやスクリプトを最初から書くという道徳的優位に隠れている『AIがこれを書いた』と指さすだけの人間だ。デプロイもできず、適応もできず、issue tracker がこういう態度を見せる場所ではないことさえ分かっていない」
[1] https://news.ycombinator.com/item?id=43077833
詳しくは読んでいないが、「今回のリリースでは6件のCVEが修正された。6件すべてが VulnCheck によって CNA として割り当てられた。影響を受けるバージョンはいずれの場合も 3.4.2 以下である」という一文は、「なぜ？」に対するかなり強い答えに見える
https://download.samba.org/pub/rsync/NEWS#3.4.3
最初の反応としては、当然どこかへ行けと言いたくなるはずだ
「大衆」がプロジェクトを引き継いで保守したいならフォークできるが、感謝されにくい仕事だ
それに、オープンソースプロジェクトでどんなツールを使うかを変えるのに理由が必要なわけでもなく、その理由をあなたに説明する義務もない
あの issue の立て方は本当に不快だが、メンテナたちが rsync に AI を放り込んだように見えるのは理解できない。なぜそんなことをしたのだろう？ すでに名声と信頼を得ていて、特定のニッチの先頭に立ち、市場圧力からも自由で、人々はそのツールを好み、やるべきことを正確にきちんとこなしているのに、なぜ比較的実験的な寄せ集めに手を出すのか？
まるで Matrix にある「原始的な人間の精神は楽園を受け入れられない」という短い独白のようだ。完璧なツールを作り、勝ち取り、ニッチではほとんど代替不能で、信頼でき、比喩的には誰もが知る名前にまでなった。それを賭けに出たり、いじったりするのは誰にとっても筋が通らず、本当に困惑する
それでも、公式 issue トラッカーでああいうやり方をするのは依然として本当に不快な行動だ。態度も悪いし、善意も感じられない
だが今では、AI がどこでも純粋にプラスだとは見えず、生成 AI の利用に対するこの反発を、大衆による良い方向への修正だと見ている
LLM 利用の即時的な満足感について書かれた文章があるが、この手のツールを使う人たちと多く接するほど、これが本当に核心の問題かもしれないと思う。私たちの生物学はそれに耐えられない
本来はとても賢い人たちが、スロットマシンにそう言われたというだけで本当に愚かなことをし、スロットマシンが失敗したときには無力になるよう訓練までされてしまっているのを見ている
私は進歩の見えないラッダイトのように扱われるが、同僚たちが意味のない ベンチマーク を作り、AI が作った美しいグラフを貼っているのを見る
すると、笑って良い仕事のふりをするか、そのベンチは定数に張り付いた区間をテストしているから無意味だと叱るかのどちらかを選ばなければならない。どちらにしても、彼らを賢い同僚ではなく 7 歳児のように扱うことになる
rsync のメンテナたちが、完璧で責任感のあるメンテナから無能な子どもまでのどこに位置するのか、実のところ私たちには分からない
ただ、少し話がそれる危険を承知でこう思う。Rsync のような成熟したソフトウェアには、変更行数のような動きは必要ないという点はさておき、メンテナたちが最善の意図でプロジェクトを運営していると仮定しよう
これがオープンソースで起きているなら、クローズドソースソフトウェアの品質 はいったいどうなっているのだろうか？
AI の利用量、つまり入力量が成功指標のように従業員評価に組み込まれ、人々は AI による大規模解雇の脅威でパニック状態にある
ぞっとする
https://github.com/RsyncProject/rsync/issues/929#issuecommen... が示しているのは、もはや古い Darwin と Linux < 5.6 では動かないという点で、Linux 5.6 は 2020 年に廃止予定となったバージョンだ。そのほかにもいくつかバグがある
メンテナが古いシステムをサポートし、変更が及ぼすすべての影響を把握していることを期待するのは無理だ。AI でやったにせよ手作業にせよ同じだ
ちなみにバグそのものは Claude Code が作った 30656c5e で入り込み、おそらく不十分な人によるレビューとテストも伴っていたようだ
https://github.com/RsyncProject/rsync/commit/30656c5e
誰かが AI を使って最近の rsync を二分探索したもの: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
誰かがさらに多くの Claude Code で直そうとした試み: https://github.com/RsyncProject/rsync/pull/930
関連チケット: https://github.com/RsyncProject/rsync/issues/915
30656c5e の直前のコミットに 回帰テスト を追加し、機能を維持したまま今後そこへリベースしていくことを勧める
これは「望まれない新機能」ではなかった。Tridge はバグ報告に関係する セキュリティ問題 を修正していたのだ。共感する。私たちは皆、セキュリティ問題に痛めつけられている。直すのは任意ではない
10 年物のソフトウェアに戻ってこれを処理するのが楽しいとは思えないし、だからこそ tridge が取り組んでいる点には感心する
私もこの混乱を乗り切るために LLM を使うという罪を犯している。tridge が何をしているのかは分からないが、私は LLM が吐いたコードを 1 行ずつ確認している。それでもバグが紛れ込むリスクは明らかに大きい
長いことそのコードを見ておらず、以前ほど詳しくもない。だからバグが紛れ込むこと自体はそれほど驚くべきことではない
この炎上で奇妙なのは、最初に不満を述べた人が自分のバックアップシステムを非常に守ろうとしているようなのに、tridge のコミットはたった 2 週間前だったという点だ。tridge が優秀なのは分かるが、こういうものは当然アルファソフトウェアのように扱うべきではないのか？ 何を考えていたのだろう？ その人も信頼できるシステムの作り方を少し学ぶ必要があるのかもしれない
数年前なら、この種の投稿が Hacker News のメインに上がる確率はほぼ 0 に近かったはず。内容の正しさとは無関係に、ここにはどんな振る舞いが受け入れられないかを理解していないような一般大衆が溢れてはいなかったからだ。
ここで言っているのは、この issue の暴力的な言葉遣いのことだ。だが今では、最も obvious なことさえ区別できない人たちに囲まれている。
Please Do Not Vibe Fuck Up This Softwareという issue を立てるのはまったく適切ではない。それは、メンテナに対してプロジェクトの方向性に同意しないと伝えるやり方ではない。この issue は完全に無価値だ。むしろ「vibe coded のせいで壊れた」というバグ報告のほうがまだましだった。
これは核心を突いている。どのバグ報告も、主張されている
--compare-dest=の回帰を文書化しようとすらしていない。Ctrl-F しても、compare-destに再び言及した人は見当たらなかった。無価値な AI 怒りコメントを書いている人たちは、Opus 4.8 に rsync 3.4.3 と 3.4.1 を走らせて回帰を徹底的に文書化し、壊したコミットを
git bisectで特定させて、1000 倍は専門的で有用なバグ報告を作らせることもできたはずだ。社会に人間の仕事を AI の仕事より高く評価してほしいなら、人間にしかできないような愚かな振る舞いは避けたほうがいい。
normiesみたいな見下した表現を使うことにも同じことが言える。メインに上がったのは、重要な作業に毎日使っているソフトウェアについて、他の人たちも同じように感じているからではないのか。
GitHub issue が陳腐で、確かに感謝されにくい仕事なのはその通りだが、現実的に見て rsync は多くのセンシティブなパイプラインの礎だ。
本当に的外れだと信じるなら、礼儀正しい対応は issue を閉じることだ。
何がそれほど明白なのか、私はまだよくわからない。私には「やめろ。お前は何もわかっていない。手で 0 個の機能しか出荷していない。お前のコードに依存している人は誰もいない」のほうが、
please do not vibe fuckup this softwareよりずっと暴力的に見える。あの issue スレッドで、誰か実際に issue の説明をしたのか？ 再現手順、期待される動作と実際の動作、といったものだ。
これは issue tracker に投稿されたものだ。「コミットメッセージに Claude への言及があり、Bluesky の誰かが、自分が経験した不特定の問題はそれらのコミットに関係していると思っている」というのは、実行可能な issue ではない。
他の議論をすべて脇に置いても、自分のプロジェクトなら「再現情報不足」で閉じてロックしていただろう。AI、fork、怒りの吐き出しに関する一般論をするにはもっと適切な場所がある。
Linux < 5.6 の利用者は GitHub でビルドできない。私にはかなり軽微な回帰に見える。5.6 のメンテナンス版、主に拡張セキュリティ版を使っている人たちなら、ディストリビューションのメンテナがビルド失敗を見つけて適時修正できるはずだ。
パストラバーサル攻撃への hardening が、chroot なしでネイティブ rsync プロトコルを使う利用者に障害を引き起こしている。皮肉なことに、
chroot = noは強く推奨されていない。ネイティブ rsync を自動化された方法で使うべきではないし、そもそも使わないほうがよいと勧めたくなるかもしれない。該当コミットが修正している CVE は、まさにこのユースケースに当てはまる。
https://www.cve.org/CVERecord?id=CVE-2026-29518
daemon + no chroot が必要だ。
daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.したがって影響を受けるワークフローは、最も脆弱なワークフローということになるのに、人々はバージョンを戻せと勧めているわけだ。
しかも、回帰テストがこれを検出すべきだったというなら、そのテストは以前から書かれていなければならない。
FOSS プロジェクトについて忘れている人もいるようだ。
「15. 保証の否認
適用法が許す限り、このプログラムにはいかなる保証もない。書面で別段の明示がない限り、著作権者および／またはその他の当事者は、本プログラムを『現状のまま』提供するものであり、明示であれ黙示であれ、いかなる保証も行わない。これには商品性または特定目的適合性についての黙示の保証が含まれるが、それに限定されない。プログラムの品質および性能に関するすべてのリスクはあなたが負う。プログラムに欠陥があることが判明した場合、必要なサービス、修理または修正に要する費用はすべてあなたが負担する。」
私は、プロジェクトが下したあらゆる決定、コミット、パッチ、マーケティング、その他の判断について、不満を述べ、愚痴をこぼし、批判し、怒り、あるいは別の形で論評する権利を留保する。こうした論評は、いかなる目的への適合性も保証せず、正しさ、有用性、親切さについての黙示の保証も含まない。私の論評が望まれないものだったと判明した場合、あなたはそれを害のない場所に突っ込んでおく権利を留保する。
望まれない FOSS プロジェクト批判に遭遇した際の参考として、この免責条項を表示してもよい。
人々が「彼らは好きにしていい」という態度が双方向だと、なぜ理解できないのかわからない。ユーザーも好きにしていい。気に入らなければ表明できる。
issue コメントのひとつにこうある。
「ホームレスに無料のスープを配っているからといって、その中に放尿していいわけではない」
当の issue はすでにめちゃくちゃになっていて、あなたの論点もそこで既に出ている。誰もがもっとうまく対処できたはずだが、法的文言を盲目的に引用しても解決はしないし、状況が良くなるわけでもない。
この話題について HN の投稿を3回目読んでいる。毎回、同じツイート、あるいは Mastodon/Bluesky 系で何と呼ぶのか分からないあの投稿が繰り返されるだけだ。実際に問題をデバッグした人はいるのか？
原因は雑に生成されたコードだったのか、それとも本物のセキュリティ修正がたまたま壊してしまったのか？ 人間でもまったく同じようにやり得た形で、という意味で
この反AIヒステリーは典型的なモラルパニックだ
すべてのモラルパニックがそうであるように、1番が事実かどうかは完全に二次的だ。核心は2番でほとんど性的な解放感を得ることにある
この件では rsync にAI生成コードがあることは分かっている。今や有用なソフトウェアの大半がそうであるように。しかしオンラインでは毎日魔女狩りを目にするし、すべての魔女狩りがそうであるように、告発が事実かどうかはあまり重要ではない。ヒステリーそのものが目的なのだ
AIの周りで起きている怒りは、大衆が誤解しているとかメッセージが間違っているからではなく、物理的現実の問題だ
この一つのものが大量解雇の口実として使われており、テックCEOたちはほぼ毎日のように他のあらゆる人の仕事まで奪うと言っていて、大手クラウド企業は部屋の酸素を全部吸い尽くしている。ゲーム業界ですら安全ではなかった
これを「ただの典型的なモラルパニック」だと見る態度は、海がどちらに引いているかを見て、そちらへ正面から走っていくようなものだ
読み進めると本人も「魔女狩り」「ヒステリー」といった感情的な言葉を使っている
これが本当に魔女狩りなのか？ そしてインターネットの向こうの人たちが性的解放感に近づいていると分かるのか？
他人の感情的な言葉や雑な思考に、本人も同じやり方で反応しているだけではないのか？
いつから GitHub の issue は他プラットフォーム上の投稿のスクリーンショットを上げる場所になったんだ？
こういう行為はミームや娯楽コンテンツを上げる場所でしか見たことがない
実行可能なバグ報告も機能リクエストもない。テキスト版もない。元の投稿へのリンクすらない
これを投稿した人は GitHub Issues を自分の個人 Twitter アカウントと勘違いしたのか？