Git: Rustの導入とビルドシステムでの必須化の発表

247日前原文(lore.kernel.org)

概要

Anubis は、AI企業による ウェブスクレイピング 対策のために導入されたシステム
Proof-of-Work 方式で、アクセス負荷を分散
一般ユーザーへの影響は最小限に抑制
ヘッドレスブラウザ の識別技術の開発が進行中
一部の ブラウザ拡張機能 が正常動作を妨げる可能性

Anubisによるウェブ保護の仕組み

Anubis は、AI企業などによる 過度なスクレイピング からウェブサイトを守るための防御策
Proof-of-Work （PoW）方式を採用し、アクセス時に計算処理を要求
PoWの導入により、 大量アクセス を行う自動化ツールのコスト増大
個人ユーザーにとっては 無視できる程度の負荷 に設計
サイト全体の ダウンタイム防止 とリソース保護

今後の対策と技術開発

Anubis は一時的な措置であり、将来的には ブラウザの指紋認証技術 へ移行予定
例： フォントレンダリング の挙動で ヘッドレスブラウザ を識別
正規ユーザーにはPoWページの表示を減らす方針

プラグインや拡張機能の影響

JShelter などの一部プラグインが Anubisの動作を妨げる 場合あり
JavaScript機能制限 が原因で、PoWページが正常に表示されない事例
問題発生時は該当プラグインを 無効化 することで解決可能

利用者への注意事項

Anubis はウェブサイトの 安定運用 を目的としたシステム
ブラウザやプラグインの設定により、アクセスに 一時的な制限 がかかる場合あり
問題が解決しない場合は、 管理者への連絡 を推奨

Hackerたちの意見

Rustの導入は、プラットフォームによっては不可能だったり、他のプラットフォームでは難しかったりする。誰か詳しく説明してくれないかな？

└

RustはCほど多くのCPUアーキテクチャをサポートしてないんだよね（SH4とか、もっといい例がたくさんあると思うけど）。これがGOTにとって、以前よりも面白いケースになるかもしれないね。 https://www.gameoftrees.org/

└

私の理解では、RustはLLVMをベースにしていてGCCじゃないから、LLVMをサポートしているOSに制限されるんだ。GCCはもっと多くのプラットフォームをサポートしてるよね。

└

Rustのコンパイラが一部のプラットフォーム（OS/アーキテクチャの組み合わせ）をサポートしてないから？ RESFのメンバーは、プラットフォームがRustをサポートしてないって言うことが多いけど、実際にはプラットフォームをサポートするのはコンパイラなんだよね。

└

このページを見てみて [1]、特に「Tier 3」のプラットフォームに注目してね。 [1] https://doc.rust-lang.org/beta/rustc/platform-support.html

└

ベンダー提供のCコンパイラで構築されたGitをサポートする少なくとも1つのプロプライエタリプラットフォームがあるけど、公開されたドキュメントがないからLLVMのサポートは不可能なんだ。 https://lwn.net/Articles/998115/ で「NonStop」をCtrl+Fしてみて。

└

あなたは「不可能」の意味を追い求めているね。簡単だよ。開発者には二つのカテゴリーがある：

「プログラミングが好き」「お金を稼ぐためにプログラムする」もしあなたが後者に属しているなら、ちょっと優しく言うけど、そうじゃないと聞こえるかもしれないから、読み続けてね。例えば、大手銀行に雇われてNonstopでアプリを作る場合、「コンピュータ上で動くすべてのオープンソースコードを審査しなければならない」みたいなポリシーがあるかもしれない。だから、彼が好きなgitをNonstopでRustを使って構築するためには、llvmをポートする必要があるけど、それは不可能ではないよ。不可能なのは、llvmのコードを法務にレビューしてもらうことなんだ。彼らはそれをやらないから、「ダメだ。llvmはダメ。Nonstopを作っているHPがやればいいし、それは彼らの法的な問題だ」と言うだろう。私は不可能だとは言ってないよ。もう一人の人が不可能だと言っていて、私は彼にとってどう見えるかをルーブ・ゴールドバーグ的に示そうとしているんだ。あなたも私もプログラミングが好きだし、きっとどちらもちゃんと働いているけど、彼はプログラミングが好きじゃない。お金を稼ぐためのシステムにいる人の誠実さを嘲笑するのは許されるけど、ただプログラミングが好きなら、銀行で働くことはないよ。本当に退屈だから、基本的にプログラミングが好きな人はRustをポートするのが不可能だなんて言わないよ。分かる？難しいのは、Jane Streetの人たちやTwo Sigmaの人たちは、本当に若い子たちで、いい人たちなんだけど、あまり長くそこにいないから、まだプログラミングが好きなんだ！彼らは銀行のために働かなきゃいけないと感じているけど、実際はニューヨークに住んで毎晩カクテルを楽しむのが楽しくて誠実だと言えばいいのに。このフォーラムはメーリングリストと同じ問題を抱えていて、一見すると「gitでハッシュマップを使えること」についての話に見えるけど、実際は「銀行家」についての話なんだ。銀行家たちは、どこに行っても自分たちのライフスタイルを可能にしてくれる人たちに出会う。例えば、時間をボランティアしてくれるgitの開発者や、彼らが行くバーのバリスタの親たちが、バリスタの家賃を払っているわけで、銀行家たちはそういう人たちを嫌っている。そして、彼らは「自分以外が問題だ」と言う。まだ気づいていないんだ。

└

簡単に言うと、Linuxシステムでは、ライブラリはシステムライブラリじゃないと、本当のOSライブラリやAPIが存在しないってこと。RustはABIがないから、(本物の)共有ライブラリもない。Debian: https://www.debian.org/releases/trixie/release-notes/issues.... 長いコメントを書いたのに、うっかりタブを閉じちゃったよ。!!@@! Rustを含むパッケージを古いハードウェアで作ることをお勧めするけど、静的リンクのせいで頻繁に再ビルドしなきゃいけないことを忘れないでね。クリーンビルドをすることも大事だよ。必要な共有ライブラリを使って、楽にするのが期待されてるから。Rustの人たちは、こういう押し方をするとCよりも嫌われるかもしれないって考えてみるべきだと思う。安定したABIや共有ライブラリについての批判をそらそうとするのはやめた方がいいかも。Linux OSはそれを必要としてるし、君のためにOSアーキテクチャを変える人はいないからね。特に重要なソフトウェアアーキテクチャの部分では、もっと保守的であるべきだと思う。

これって、gitのユーザーとして私にどう役立つの？

└

私の予想では、私たち（私もgitのユーザーです）は、気づかないと思います。

└

Rustは、Cよりもソフトウェアを構築するためのツールとしてはずっと優れています。より良いツールでソフトウェアを作ると、たいていはより良いソフトウェアが得られます（少なくとも最終的には、長期的には、移行期間中は一時的に悪化することもあるけど）。

└

将来的にはもっと信頼性が高く、速くなるかもしれないし、機能も増えるかも。でも、効果が見えるのは10年くらい先だと思う。

└

gitの開発者たちは引き続き貢献する意欲を持ち続けるだろうね。（これはRustに特有のことじゃなくて、OSSの技術的選択が一般的にユーザーを最優先にしていないってことだと思う。）

└

適時のセキュリティアップデートがないからだよ: https://www.debian.org/releases/trixie/release-notes/issues....

└

それはダメだね。Gitが使えるプラットフォームの数を制限しちゃうから。

└

Gitの開発がモダンで、安全かつ速くなるってこと？

git 3.0について、何か新しい情報はあるのかな？私の（すごく限られた）視点からすると、gitは2.xに落ち着いていて、互換性を壊す理由はないと思ってたんだけど。

└

SHA-256がデフォルトのハッシュになるでしょう。

└

https://git-scm.com/docs/BreakingChanges#_git_3_0

もしかしたら私はただの年寄りで愚痴っぽいだけで、Rustのようなもっと大きくて良いもののために退くべきなのかもしれない。でも、今はGitやカーネルを扱うためにCだけを理解すればよかったのが、Rustも知っておかなきゃいけなくなった。ツールチェーンの複雑さが増していて、これらの言語の混在が参入の障壁を高めている。私はGitにかなり投資していて、ツールを学び、多くのプロジェクトをその中で構築してきた。自分のGitクライアントを作ったり、Gitリポジトリを使ったウェブサーバーを構築したりしている。Gitのハック可能性を失いたくないんだ。

└

自分のGitクライアントを作ったり、Gitリポジトリを使ったウェブサーバーを構築したりしている。Gitのハック可能性を失いたくないんだ。彼らはずっと働き続けるだろう、なぜならリポジトリのフォーマットはgitが書かれている言語の影響を受けないから。

└

私はただの年寄りで愚痴っぽいだけで、Rustのようなもっと大きくて良いもののために退くべきなのかもしれない。あなたはそうだね。これは「新しいことを学びたくない」というしっかりした領域で、業界では通用しない態度だよ。いずれにせよ、Rustは通常Cよりも簡単だし（バグの多いCを除いてはとても書きやすい）、GitやLinuxのコードベースを実際に学ぶよりも確実に簡単だよ。

└

俺もいくつかパッチを送ったけど、また貢献するためにRustを（やっと）学ばなきゃいけないのはちょっとテンション下がるな。もう時代遅れなのかな…

└

確か、gitはすでにいくつかの言語を使ってるよね。githubによると、50%がCで、38%がシェル、4%がperl、4%がTCL、1%がPythonだって。だから「別の言語」って言っても、あんまり影響はないと思う。特にperlやTCLはちょっと変わった言語だし。でも、Linuxやgitみたいな大きなプロジェクトにとっては、これは実際に統合のステップになるかもね。何十年もかけて成長して、いろんなものを重ねてきたわけだから。プロジェクトが何なのか、どこに向かっているのかは大体わかってきたし、そろそろ安全性やパフォーマンスを考えて、古いハックを取り除く時期だと思う。Rustはいい選択だと思うな。

└

今はGitやカーネルの作業をするためにCだけを理解していればよかったのが、今はRustも知っておかなきゃいけない。複数のプログラミング言語に精通していないソフトウェアエンジニアをまだ見たことがないよ。これは問題じゃない。

└

同じ気持ちだよ :) でも心配しなくて大丈夫。Rustなしでも古いgitをビルドして使うことができるから。もちろん、子供たちが「より良い」プロトコルに変更するまでの間はうまくいくけどね。年を取って不機嫌になると、そういうことに対してだんだんどうでもよくなってくるし :) 子供たちよ、今すぐダウンボートして消え去らせてくれ :) 俺が気にするかよ…

└

Perlを取り除いてRustを追加するのは、むしろ複雑さを減らすことになるんじゃないかな。

└

別の視点から見てみて。特に若い開発者たち（俺も含めて）は、CよりもRustで開発する方がずっと好む人が多いし、彼らの中にはCを書く方法（未定義動作を避ける方法を含む）を学びたくない人もいるんだ。 > 自分でGitクライアントを書いて、Gitリポジトリを使ったウェブサーバーを構築したことがあるよ。Gitのハック可能性を失いたくないんだ。GitプロジェクトがRustを使うことで、君のその能力にどんな影響があるの？

ちょっと気になるんだけど、GitにRustを導入する理由は何なの？Gitの開発には詳しくないけど、ただのユーザーだから。俺の印象では、もうすでに完成されたツールで、新しいコードを書く必要はあまりないと思う。ちょっとした修正や改善はあるけど、それが新しい言語を使う理由にはならない気がする。逆に、Linuxの開発にRustを追加するのは理解できる。新しいドライバーは常に書かなきゃいけないからね。俺が見落としてることを誰か説明してくれない？

└

Cは危険だね。

└

https://lore.kernel.org/git/ZZ9K1CVBKdij4tG0@tapette.crustyt... には数十件の返信があって、読むにはいいスタート地点になると思うよ。それ以外にも、そのリストでRustを検索してみて。（ちなみに、私は最初の質問にだけ答えてるだけで、ここやリストでの賛否の議論には触れてないからね。誰か他の人がやるだろうけど。）

└

Gitは常に機能が増えてるけど、基本的な機能はあまり変わってないように見えるね。変更履歴を確認したいなら、GitリポジトリにはRelNotesがあるけど、GitHubのブログのGitカテゴリーの方が読みやすいリソースだと思うよ: https://github.blog/open-source/git/

└

gitは、jjやgit-branchlessみたいなツールを使うまでは完璧に感じるよね（後者はRustでのメモリ内マージみたいな機能があるし）。

└

気になるんだけど、GitにRustを導入する理由って何なの？もっと多くの開発者が必要なんだ。古いCプロジェクトには、もう新しい開発者があまり来ないし、Gitプロジェクトに参加してCコードを書く人なんてほとんどいないよ。一方で、「Rustで書き直せ」派は、今のところ喜んで参加してRustの良さを広めるだろうね。

└

Rustのプロモーターたちの現状を把握するために。

└

Gitに関わる開発者たちは、それが自分たちの仕事をより良くすると思ってるんだ。それ以上の理由が必要？ユーザーに対して必ずしも正当化する必要はないよ。

└

Rustの全体の目的は、Cとその中で書かれたコード（可能な限り多く）を最終的に置き換えて放棄することなんだ。Cを使い続けることの潜在的なコストは、全世界で数十億ドルに達するかもしれないし、それ以上かも。2025年には、実際に使っている人たちは100% Rustのjjを使ってるから、Gitが競争力を保ちたいなら追いつかなきゃいけないよ。

開発者文化がクロスコンパイルツールチェーンの使い方を忘れちゃったってことかな？私がキャリアを始めた頃は、開発者が実行されるシステムやプラットフォームとは違うところでソースコードを操作するのが普通だって理解されてたよ。ソース管理、編集、コンパイル、実行は、異なる計算空間で行われるって考えられてたし、その間にコピーやステージングのステップがあることもあった。ソースコードファイルがある同じシステムでビルドしたプログラムを実行できると思ってたら、かなりナイーブだったね。これが私たちが管理していたビルドルールのかなりの部分だった。例えば、設定ステップは、測定・特性評価されるターゲットプラットフォームがビルドツールを実行しているプラットフォームとは違うことを理解しておく必要があった。そして、ビルドしたオブジェクトを実行するには、リモートファイルのコピーやリモートプログラムの呼び出しが必要になることもある。

└

実際、Rustのツールチェーンは、今まで使ったどのフルコンパイル言語よりもクロスコンパイルをずっと簡単にしてくれるよ。--targetフラグを設定するだけで、100種類以上のプラットフォームに対応できるし、ほとんどどのホストプラットフォームでもちゃんと動く。問題は、いくつかのGit開発者が自分たちの開発マシンに対して古くて硬直した要件を持ってるってことみたいだね。

└

大多数の開発者は、そもそもクロスコンパイルを学んでないんじゃないかな。クロスコンパイルはほぼ常に二流扱いだし、外部プロジェクトで正しく動くとは期待してないよ。Linuxディストロも諦めていて、FedoraなんかはRaspberry Piみたいなプラットフォームで実際のターゲットハードウェアでコンパイルを行うことを主張してるから、ちょっと狂ってるよね。その結果、ほとんど誰もそれを動かすために努力しないんだ。

└

開発者文化がクロスコンパイルツールチェーンの扱いを忘れてしまった結果、鶏が帰ってきたってことかな？君のコメントが理解できないよ。Rustを完全に無視して、現代のクロスコンパイルの状態は完全な災害だよ。Linuxは特にひどくて、glibcは80年代に縛られたひどいアーキテクチャのゴミの山だ。どんなLinuxハードウェア環境でも、任意の最小glibcバージョンをターゲットにするのは簡単なはずなのに、glibcとLinuxディストリビューションはそれを可能にしようとすらしない。Linuxのツールチェーンは、クロスコンパイルにとって正しいことの反対であるデフォルトのシステムライブラリを使わざるを得なくする。Zigはクロスコンパイルを可能にするために大変な努力をしているけど、実際にクロスコンパイルをサポートしようとするプロジェクトはほとんどないよ。

このシリーズは、次のリリースでRustを必須にしたいという別のスレッド[1]に対する反応だったんだ。著者の提案は、代わりに中間的な立場を取って、Rustをオプションの依存関係として使うことだった。後で必須になる時期は、Rustサポートがgccに追加されるタイミングに基づいて決まったんだ。これによって、gccをサポートするプラットフォームも含まれるから、スムーズになるだろうね。[1]: https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...

└

GCCコンパイラコレクションは、当たり外れがあるよね。例えば、gcjなんて誰も使ってないし。標準すらない言語のために良いコンパイラを実装できるとは思えないな。将来的には、Javaの時みたいに、実装がすぐに時代遅れになっちゃうだろうし。

Rustは、関数型プログラミング言語が抱えるのと同じ問題を抱えてるよ：学習曲線が急で、複雑さが高い。高い複雑さは、ランタイムエラーをコンパイル時に押し戻すことを意図してるけど、その分言語が苦しむことになる。Rustは複雑さの火事みたいなもんだよ。だから、私はこれが良いアイデアだとは思わない。カーネルもRustをある程度拒否してるしね。カーネルは、Haskellタイプのシステムや、どのコードがどのコードを呼び出すかを隠すことができるリスプレベルのマクロシステムを追加するほど複雑じゃないから。serdeのコードは、この理由で探るのがすごく難しい。これに対して、GoのUnmarshallはずっと追いやすいよ。

└

「Rustは複雑さの火事だ」って言葉には思わず目を roll しそうになったけど、実際そうじゃないよね。特にC++と比べたら。でも、その後の段落では完全に嘘をついてるし。

└

実際、RustはTypescriptを書いたことがある人には結構簡単に習得できると思うよ。リントを使って参照やResultのアンラップ、エラーキャッチを理解できるならね。それに、Rustの構文はかなり優しいし。LinuxがRustをカーネルから拒否したわけじゃないよ。

└

それは…面白い視点だね。個人的には、Rustを含む関数型プログラミング言語の方がCやGoよりずっと明確だと思う。特に、コンパイラに多くの情報をオフロードできるからね。Serdeの例はちょっと変な感じがするけど、私はSerdeのコードで問題に遭遇したことがないし、Goを本番で使ったときはほぼ100%の確率でGoのUnmarshalやその…面白い実装をデバッグする必要があったよ。それに、最後に確認したとき、カーネルはRustを拒否してなかった。特定の2人の開発者の間で、ヘッダーをどこに置くべきかの対立があっただけだから、ちょっと違う話だね。

└

高い複雑さは、ランタイムエラーをコンパイル時に戻すために意図されている。これを許可するエルゴノミクスは、借用チェッカーと同じくらい重要だと言えるかも！

└

Rustは複雑さのタイヤ火事だね。でもCはそうじゃないの？

└

Cはシンプルだよ。良い、速い、安全なCは複雑だけどね。RustはCより初期の学習曲線が高い。でも、最低限のRustと速くて安全なRustのギャップはCよりもずっと小さいよ。

└

そうだけど :) Rustが複雑なのは、関数型の特性があるからじゃなくて、他のデザインの選択肢によるものだよ。確かに複雑だけど、外から見ると「怖い」印象があるかも。最近、ついに学んでみたけど、思ってたよりずっと扱いやすかったよ。

タイトルはちょっと誤解を招くね。Rustはビルドシステムで必須になるけど、将来のパッチに対して必須になるわけじゃないよ。

└

ありがとう！それを上のタイトルに追加したよ。もし何か不正確な点があれば、また変更できるからね。

└

それはどういう意味？ビルドシステムを構築するために必須なの？それともアプリケーションをビルドするためにも必要なの？

Rustをあちこちに導入しようとする意味って何なの？Gitは成熟したソフトウェアだし、新しいコードを書く必要がそんなにあるとは思えない。しかも、RustはCに比べてかなり複雑だよ。もし本当にクラスやテンプレートが必要なら、C++98を使えば最近のC++スタンダードやRustに比べてまだクリーンで理解しやすいものが得られるよ。

└

新しいコードを書く必要があるとは思えないな。1年前や5年前にも同じことを言った人がいたかもしれない。進歩を忘れがちだけど、カジュアルなユーザーには見えないところでたくさんのことが進行中なんだ。Gitリポジトリのgit logを見てみて。過去1年間で、週にほぼ100回のコミットが安定して行われてるよ。それは新機能の可能性については何も言ってないけどね。VCSの分野にはまだまだ解放されるべきことがたくさんあるよ。例えば、jjみたいな新しいツールを見てみて。さらに、セキュリティの状況は日々厳しくなってきてるから、脆弱性に対して積極的に対応する必要がこれまで以上に求められるだろうね。

ハクソク