Debianは一人じゃないよ。多くのパッチはCVEのバックポート修正だし。「このプロジェクトは古いバージョンのgccでしかコンパイルできない」みたいなこともあるから、選択肢はそれを捨てるか修正するかだよね。特定のアーキテクチャでしか現れないバグもあって、開発者がamd64しか使わないから、他の環境でコンパイルや実行をしないんだよね。だから間違った仮定をしちゃう。あとは、Pythonが毎回のリリースで標準ライブラリモジュールを削除して、いろいろ壊しちゃうから、Pythonの外で別にパッケージ化されることもある。まだリリースされていないプロジェクトからのバグ修正を選んで持ってくることもあるし。Debianの開発者が他の誰よりも間違いを犯しやすいと思う理由はあるの？Debianはほとんどのプロジェクトが持っていないような厳密なテスト環境を持っているのに。

それはパッチが何かによるよね？もし欠けているマニュアルページを追加するだけなら、何が悪くなるか分からないよね？ビルドオプションを変更する（例えば、機能を有効化または無効化する）ことはパッチなのか、それとも期待される変更なのか（もしその設定オプションが悪いなら、上流にどのくらい責任を問うべきなのか）？デフォルトの設定ファイルはどう？それによってソフトウェアがより安全になったり、逆に安全でなくなったりすることもあるし、TLSやSSHで使う暗号がどうなるかとか。

でも、こういうことをするソフトウェアをすべて捕まえられる保証はないよね :D

このポリシーはnixpkgsには欠けてるけど、技術的な理由からビルドプロセスには似たようなポリシーがあるんだ。だから、nixpkgsを通じてNixOSにspotifyやsignal-desktopを追加できるけど、彼らは自分たちで更新することには成功しないんだよね。でも、試みるかもしれなくて、それがDebianのガイドラインに違反することになる。難しいところだな — 俺はサービスアーキテクチャに依存する現代の商業ソフトウェアが好きなんだけど、10年から15年後にはその会社が倒産したりサービスの利用条件が変わったりして、なんか壊れた状態になるのが確実なんだ。だから、パッケージシステムの長期的な健康を気にする、あまり興奮しない人たちが守っている原則には感謝してるよ。

残念ながら、これはまだDebianポリシーの一部ではなく、Debianには異なる深刻度のプライバシー問題がまだたくさんあるんだ。 https://wiki.debian.org/PrivacyIssues

opensnitchがDebian trixieでも利用可能になったのは嬉しいよ、Debianがまだ見つけていない問題を軽減するためにね。

最近、visidata(1)が電話をかけることを知ってめっちゃがっかりした。多くの人がその機能の削除を求めているのに、Debianパッケージでは無効になってないんだよね。: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001647 https://github.com/saulpw/visidata/discussions/940

2年前にUbuntuからDebianに切り替えた理由の一つだね。もう一つの理由はsnapだった。

彼らは自分たちのGoフォークを持ってるの？テレメトリコードが入ってる他のたくさんの例の一つだね。

ほとんどの良いディストロはこれをやってるよ。例えば、SUSEは最近「電話をかける」からパッケージを禁止したんだ。例えば、サイドリーディングをしたとかね。 https://security.opensuse.org/2025/05/07/deepin-desktop-remo... Debianも確かにこれをやってる。リリース版ではFFがテレメトリを無効にしてる: https://wiki.debian.org/Firefox

これがDebianの好きなところの一つだね。

なんでGNOMEがホームコールを止められないの？（Debianインストールで）ここでDebianのVMを立ち上げるたびに、OSXホストシステムでLittle Snitchがポップアップして、GNOMEのウェブエンドポイントへの変な接続があるんだ。これが私の大きな不満の一つ。

Debianのパッチが、既存のソフトウェアよりもCVEに値するバグを引き起こすという統計はある？OpenSSLは本当にクリーンな歴史を持っているわけじゃないし。パッチがOpenSSLのメーリングリストに投稿されて、事前に承認コメントがあったことも忘れないで。そうは言っても、すべてのパッチをレビューするペネトレーションテストチームがいるかって聞いてるなら、いないよ。99.999999999%のソフトウェアにはそんなものは存在しないから。

https://research.swtch.com/openssl で詳しい背景がわかるよ：opensslはその変更について尋ねられて、どうやら承認したみたい（みんなが何を承認しているのか理解していたかは別の話だけど）。なぜopensslがそのパッチを採用しなかったのかは不明だけど（他の人たちが運が良かったのかな？）、もしそのパッチが適用されていたら、反応はどうだったんだろうね（またはビルドスイッチで隠されていたら）。

Debianは、配布の理由で厳密に必要ではないパッチをたくさん当ててるよ。例えば、GnuPGのパッチはこんな感じ: * https://udd.debian.org/patches.cgi?src=gnupg2&version=2.4.7-... そこには基準に関する政治的なことがたくさん含まれてる。具体的な例としては: * https://sources.debian.org/src/gnupg2/2.4.7-19/debian/patche... 上流のGnuPGプロジェクト（と彼らが属する基準派）は、ユーザーIDなしのキーの使用に反対してるんだ。これは潜在的なセキュリティ問題だからね。また、RFC4880のOpenPGP標準でも明確に禁止されてる。Debianのプロセスを通じて、そういうキーの支持者たちは上流プロジェクトと基準の立場をバイパスしてるんだよ。

OpenSSLが関わるなら、まずは他の全員に疑いの余地を与えるよ。なんでかって？Heartbleedがあったからさ。

それが電話をかけることと何の関係があるの？

こんにちは、いつものように思うんだけど（笑）、この件を覚えてるよ。もし記憶が間違ってなければ、opensslがメモリを無断でアクセスして、キー生成のためのランダム性/エントロピーを集めてたんだよね。それでvalgrindがメモリリークの可能性について文句を言ってた。valgrindはメモリ管理の問題を検出することに特化したプロファイリングツールだよ。* https://valgrind.org/ それなのに、メンテナはそのアクセスをコメントアウトしたり無効にしたりしてた…ミスは誰にでもあるけど、Debianコミュニティはこの問題をうまく処理したと思う。彼らはいつもそうしてる印象があるし。知らんけど…私は企業に関連するディストリビューションよりも、Debianのオープンでコミュニティ主導のアプローチが好きだな。最後に、彼らには社会契約があるし。要するに、少なくとも私にとっては、これはDebian GNU/Linuxディストリビューションの利点であって、反対の理由ではないよ :)) ただの私の意見ね。

それは、プロジェクトにマニュアルページが欠けているか、すごく悪い場合にだけ起こるんだ。

通常、Debianのマニュアルページの作者やパッケージメンテイナーがそれをアップストリームに送るんだ。同じことがパッチにも当てはまる。時々、アップストリームはマニュアルページを欲しがらなかったり、別のフォーマットを求めたりして、Debianの人はそれを書き直す時間がないこともあるんだよね。

私は何年もNetBSDのためにソフトウェア（主にGnome 2.x）をパッケージ化してた。ビルドの修正や改善のために必要なローカルパッチをアップストリームしようとほぼいつも努力してたんだけど、疲れるし、 uphill battleだったよ。ほとんどのパッチは何ヶ月も何年も無視されて、「これまだ必要？」とか「パッチを更新して；もう適用できないよ」みたいな反応が返ってきた。全体的にかなりの労力がかかったから、パッチが彼らのディストリビューションに残るのは…「普通」だね。

もう一つの問題は、これらのmanページが古くなったり（あるいは完全に間違ってたりすること）だね。全体的に見て、これは1995年に取り残されたDebianの方針の一つだと思う。最近は他にも合理的な方法でドキュメントを取得できるし、manページは特定のプログラムには役立つけど、他のプログラムにはあまり役立たないこともある。

パッチとその説明はここにリストされてるよ: https://udd.debian.org/patches.cgi?src=xscreensaver&version=... 編集: 見た目の理由のものは見つからないな。

もっと良いことをする別のディストリビューションを使ってるの？

ソースの改変をされたのは本当に最悪だった それを維持する立場として、その気持ちはよくわかるよ。私もそんなことされたら気分が良くないだろうな。ユーザーとしては、彼らが必要だと感じた改変はどんなものだったのか、具体的にライブラリに何を変更したのかが気になるね。

自由なゲームのアップストリームとして似たような経験をしたことがある。彼らも時々、バグをこちらに転送してきたよ。

あなたは、DebianがOSの他の部分との統合のためにアップストリームソフトウェアに大きな変更を加えていて、Archは全く何もしていないと暗に言ってるようだけど、どちらも真実じゃないよ。