データが変わったら、トレントクライアントはどうやってそれを拾って変更をダウンロードするんだろう？

CIは計算リソースの無駄遣いの一つだと思うけど、地図データがライブラリや他のコードと同じように乱用されるとは思えないな。

CIサーバーからのリクエストを確実に特定できるのかな？

GPKGファイルを「クエリ」するウェブアプリがあるんじゃないかな。Parquetは精密にクエリできるけど、GPKGでも同じことができるかはわからないな。

何か軽量な認証（APIキーとか、メールベースでも）を持つのはいい妥協だと思う。

ログインがないから、メールアドレスも持ってないよね。

いくつか考えられる理由があるね。1. BitTorrentは悪いイメージがある。ほとんどの人は違法ダウンロードと結びつけて考えてる。2. ちょっと複雑なファイアウォールのルールが必要で、ネットワーク管理者にそれを設定してもらうのは、理由1のせいでちょっと抵抗があるかも。非常に制限の厳しいネットワークでは、BitTorrentのせいで全く許可したくないってこともあるし。3. BitTorrentクライアントはHTTPクライアントよりも複雑で、ほとんどの会社のコンピュータやCIパイプラインにはインストールされてない（必要がないから、そしてまた理由1）。多くの人はただcurlして終わりにしたいんだよね。4. 多くの人がシードする必要があると思ってて、なぜかそれが怖いみたい。全体的に見て、理由1と、単にcurlしてすべてが動くっていう事実が大きいと思う。BTがどれだけ優れたファイル転送プロトコルか、そしてそれがどれだけ使われていないかを理解していないのが悲しいな。確か、あるゲームクライアントが裏でBTを使ってアップデートしてたのを覚えてるし、peertubeはwebtorrentを使ってるけど、残念ながらBTはあまり人気がないね。

単にhttpが持ってる「ユニバーサルクライアント」がないからだと思うし、devたちがssh/scpで持ってることが多いんだよね。そんなクライアント（自動化されたスクリプトCLIクライアントでも）を設定するのが難しいわけじゃないけど、トラッカーも必要になるし、それを維持するためのツールも必要だし。直感的に言うと、これらは不可能じゃないし、数カ所の難しいところを除けば、そんなに難しくもないと思う。要は、非常に大きなファイルやセットの頻繁なダウンロードに対する需要がどれくらいあるかってことが問題なんだよね。それが信頼性やシーディングのボリュームの問題につながって、ツールを開発して様々なRCSやファイル同期サービスと統合するための労力と対比されることになる。Git LFSみたいなものが役立つかな？ここら辺は私の理解の限界だわ。

数年前に「動的コンテンツのトレント」って概念を見た記憶があるけど、結局は実現しなかったみたいだね。実現してたらよかったのに、でも重大な問題（例えばセキュリティとか）があるのかもしれない。

コンテナレジストリみたいな感じ？ https://github.com/uber/kraken が存在してるけど、修正されたBTプロトコルを使ってるんだ。ただ、大きなイメージをたくさんのノードに配布するわけじゃないなら、中央集権的なレジストリの方が速くてシンプルで安いと思うよ。

Amazon、Esri、Grab、Hyundai、Meta、Microsoft、Precisely、Tripadvisor、TomTom、他の数十社が集まって、S3上でOSMデータをParquet形式で無料提供してるんだ。これを精密にクエリして、マルチTBのデータセットでMB単位の帯域幅だけで分析ができるよ。 https://tech.marksblogg.com/overture-dec-2024-update.html ArcGIS Proを使ってるなら、このプラグインを使ってみてね： https://tech.marksblogg.com/overture-maps-esri-arcgis-pro.ht...

ネットワークの観点から見ると、BitTorrentはひどいよね。ネットワークトポロジーを把握できないから、トラフィックがアイボールネットワークからアイボールネットワークに流れることが多くて、「安い」経路がないことが多い（これがトランジットポートの混雑を引き起こす可能性がある）。さらに、トラフィックがどこから来るかを予測する信頼できる方法がないから、キャパシティプランニングが大変だよね。それに、誰かが重いトレントをしてるときにインターネット接続を共有しようとしたことがある人ならわかると思うけど、接続数が多すぎると、ネットワーク上の非トレントトラフィックの全体的な質が下がるんだよね。もちろん、BitTorrentには大きなスティグマがあるのも忘れちゃいけない。以前はSquidキャッシュボックスが答えだったけど、httpsがそれを非常に難しくしてる。全てのデバイスにmitm証明書をインストールしないといけないからね。コンテナイメージについては、プルスルーレジストリがあるけど、これを設定するのは簡単じゃないし（サービスとしても各クライアントとしても）、クラウドプロバイダーはストレージにかなりの料金を請求するから、チェックが「普通に動く」時に正当化するのが難しいんだ。Linuxディストリビューション（CPANやtexliveなど）には、数年前からミラーネットワークがあって、これらの問題の一部を解決してるけど、OpenCachingプロジェクトもあったけど、動画メディアや公開後数時間でキャッシュに現れるパッケージ以外の様々なコンテンツをキャッシュするには持続可能じゃないんだよね。BitTorrentは魅力的に見えるかもしれないけど、問題を移動させるだけで、解決にはならないんだ。

HTTPにちょっとした変更を加えるだけで、Bittorrentの利点をかなり享受できると思うよ。HTTPの基本的な原則はそのままでね。ここでOSMにBittorrentが理想的だと思う。

ワールド・オブ・ウォークラフトは、しばらくの間、パッチ用にBitTorrentのようなプロトコルをデフォルトオプションとして使ってた気がする。 https://www.bluetracker.gg/wow/topic/us-en/10043224047-need-... その例として挙げてみる。いろんな問題やクレームがあって嫌われるようになったけど、主にブリザードが拡張パックの数週間前にパッチセットを事前にロードするっていうアイデアを思いついたから、消えちゃったんだよね。リリースの1ヶ月前に10GBのパッチを送って、リリースの1週間前にそのパッチを更新して、リリースの前日には最後の小さなパッチを当てれば、全部事前にロードされるってわけ。Netflixとかの影響でCDNの爆発的な増加も市場をかなりシンプルにしてるしね。

以前、毎週すべての開発者に巨大なファイルを配信しなきゃいけない会社で働いてたんだけど、ある時、rsyncの大群からBitTorrentに切り替えたんだ。速度がめちゃくちゃ上がったよ。

BitTorrentを使うには、マシンがリスニングしてて、何らかの形でアクセス可能である必要があるんだけど、これが多くの場合当たり前じゃないし、時には望ましくもないこともあるよね。目立っちゃうし。企業や一般的な非オタク環境で成功する可能性があるBitTorrentのバリエーションは、次のような特性を持っているべきだと思う。

• WebSocket経由で動作すること
• ブラウザで動く、インストール不要
• 反抗的な評判がないこと これが実装されてるのは明らかだから、何度も行われてると思うけど、注目を集めないことが目的だからあまり知られてないんだろうね。

APIをホスティングしてると、開発者の無責任さや無知さには驚かされるよ。これは、スキルのない人には誰にでも当てはまることだね。みんなが見つけたAPIを叩きまくってるわけじゃないって保証するよ。プログラミングがほぼ誰でもできるようになって、特に今は「バイブコーディング」なんてのもあるから、こういうことは起こるだろうね。レスポンスに429（リクエストが多すぎます）を返すか、漏れバケツアルゴリズムを使って、ジュニア開発者や見習い、バイブコーダーはすぐに自分のやってることが間違ってるって学ぶだろうね。 - シニアバックエンド開発者

たった一人のユーザーが1日に20GBのファイルを何千回もダウンロードしてるって言ってるけど、エンドポイントにレートリミットをかければいいじゃん？

正直、両方とももう少し共感が必要だと思う。クライアントは共有インフラを尊重しないといけないし、API開発者はもっとユーザーの気持ちを考えるべきだよ。

S3の「ダウンローダーが支払う」みたいな機能がもっと広く使われてないのが理解できない（AWS以外でも利用できればいいのに）。非効率な消費者には自分のコストを負担させればいいのに。大きな欠点は、支払いネットワークにアクセスできない人が除外されることだけど、レート制限付きの無料オプションがあればいいかもね。

だから、CIでプロジェクト特化のイメージを作って使ってるんだ。毎回apt-getを実行するのは時間がかかりすぎるからね。

ちょっと待って、Dockerはレイヤーをキャッシュするから、毎回ゼロからビルドしなくてもいいんだよね…？

コンテナに入っちゃうと、みんな魔法みたいにタダだと思っちゃうよね。

でも、これでデータのホスティングがめっちゃ複雑になるよね。ファイルとnginxだけだったのが、今はアクティブな認証、キーの発行、モニタリング、レート制限が必要になるんだから…確かに「正しい」解決策だけど、めっちゃ面倒だし、こんなに手間をかけずにいいものが手に入ればいいのに。これがコモンズの悲劇だね。

元のタイトルは問題ないと思うよ。OSMかどうかはあまり関係ないし、無駄にデータをループでダウンロードしてる人たちの他のケースにも当てはまるから。

そのうち別のコメントが来るだろうね。「OSMって何？」って。今のタイトルで全然いいけど。