Compiler Explorerと「永続するURL」の約束
(xania.org)- Compiler Explorerは共有リンクを長く生かすため、2012年から保存方式を変えてきたが、goo.glの終了により過去の
godbolt.org/g/abc123リンクの保全が急務となっている - 当初はコンパイラの状態全体をURLに含めていたが、2014年にはGoogleのURL短縮サービスを導入し、2016年にStack Overflowが短縮URLを禁止した後は
godbolt.org/g/abc123という迂回リンクを作った - URL長の制限がより大きな問題になった2018年以降は、状態をS3上のJSON文書として保存し、DynamoDBで短いハッシュと完全なパスの対応を管理する独自方式へ移行した
- Googleがgoo.glリンクを2025年8月に終了すると既存のgoo.glベースのリンク解決が難しくなるため、公開Webとログから見つけた約12,000件の
gリンクとそのリダイレクト先を独自データベースに集めている - 古いCompiler Explorerリンクを持つユーザーが今そのリンクにアクセスすれば保全対象に入る可能性があり、長く残すべき共有知識は中核インフラを自ら所有しているほうが安全だ
Compiler Explorerのリンク保存方式の変遷
- 2012年にはCompiler Explorerの状態全体をURL内に保存していた
- コンパイラの状態全体をURLにエンコードする方式は長くなりすぎて扱いにくく、2014年3月にGoogleのgoo.gl短縮URL対応が追加された
- 当時の短縮リンクは
goo.gl/abc123形式で、クリックするとCompiler Explorerサイトの完全URLへリダイレクトされ、その後URL内の状態をデコードしていた
Stack Overflowの禁止後の迂回リンク
- 2016年、Stack Overflowは実際のリンク先を隠せることを理由にURL短縮サービスを禁止した
- この措置はCompiler Explorerのリンクにも影響したが、当時はユーザーデータを自前で保存する意図はなかった
- 迂回策はgoo.glを使い続けつつ、ユーザーには
godbolt.org/g/abc123形式のリンクを提供する方式だったabc123はgoo.glの固有IDだった/g/abc123へのアクセスはgoo.gl/abc123へリダイレクトされる- goo.glはさらに状態を含むgodbolt.orgの完全URLへリダイレクトした
- その後はGoogle APIを使って複数段のリダイレクトチェーンを避けるようにした
2018年の独自ストレージへの移行
- 2018年にはURL長の制限がさらに大きな問題となり、すでにURL内データの圧縮も行っていた
- Compiler Explorerは状態を直接保存する構造へ変更した
- 短縮リンクのハッシュに不快な単語が含まれないかも検査していた
- 不快な単語が出た場合は文書に意図的に追加情報を入れて別のハッシュが出るようにした
- この挙動はbug #1297につながった
goo.gl終了が生んだ保全問題
- Compiler Explorerは今も
godbolt.org/g/abc123リンクをサポートしている - Googleは既存リンクが意図されたリンク先へ引き続きリダイレクトされるとしていたが、goo.glは数年前に読み取り専用となっており、2025年8月に最終終了予定となっている
- 終了後はgoo.glベースのリンクをこれ以上解決できなくなる
- 実際の
goo.glリンク自体はCompiler Explorer側ではどうにもできないが、godbolt.org/g/abc123リンクは独自データベースで保全できる
既存リンクの収集と独自データベース
- ここ数日、公開されたさまざまな情報源から既存リンクとそのリダイレクト先URLを集めている
- 現時点で約12,000件のリンクを見つけている
- Google Web検索API
- GitHub API
- 独自のWebログ
- archive.orgのStack Overflowデータダンプ
- Archive.orgが保存したWebページ一覧
- 内部的にはgoo.glよりも独自データベースを優先して使うよう変更した
- まだデータベースにない新しい
gリンクも監視している - ローカルにはsqliteデータベースがあり、本番側ではDynamoを使っている
ユーザーが手伝えること
- 古い
godbolt.org/g/abc123リンクを別途保管しているなら、今のうちに各リンクへアクセスしておくと役に立つ - リンクにアクセスすればWebログに残り、その後データベースへ追加される可能性がある
- そうでなければ、2025年8月以降にそのリンクは動作しなくなるかもしれない
- この事例は重要インフラをサードパーティサービスに依存することの危険を示している
- 「永続するURL」という約束を守るには、スタック全体を自ら所有しなければならない
1件のコメント
Hacker News のコメント
2010年以前は、リンクは永遠に維持されるものだと当然のように信じていて、ブラウザのブックマークをよく使っていた。
後になって、ブックマークのかなりの数がリンク切れで事実上使えなくなっていることに気づき、それ以降はウェブページをPDFとして印刷して保存するようになった。
リーダービュー機能がかなり安定して普及してからは、リーダービューの内容をコピーしてRTFファイルとして保存する方法に変わった。
訪問するすべてのページを保存するために SingleFile 拡張機能を使っている。
設定は簡単だが、ディスク容量を大量に消費する点には注意が必要。
$ du -h ~/archive/webpages1.1T /home/andrew/archive/webpageshttps://github.com/gildas-lormeau/SingleFile
公式の Web Archive ブラウザ拡張機能をインストールすると、訪問するすべてのページを自動的に保存するよう設定できる。
自分の解決策は、重要な内容そのものを覚えるか、少なくともどこで見つけられるかを覚えることだった。
まだ死んでいないので、うまく機能しているということだ。
リンクがタイムアウトしたら自動的に web.archive.org に飛ぶブラウザ拡張機能があるのか気になる。
ブラウザがいまだにこの気づきを反映してブックマーク機能を直していないのは、本当にあり得ない。
すべてのブックマークは、リンクだけでなくレンダリング済みページ全体のコピーも保存すべきだ。もはや存在しない可能性のある動的コンテンツに依存する元ソースだけを保存してはいけない。
開いているタブも同じであるべきだ。インターネット接続がない状態でタブに戻ったとき、ブラウザが親切にもそのタブをメモリから追い出したという理由でネットワークエラーを見たくない。
この場合は、自分が手動で更新するまで、ネットワークではなくディスクから状態を再読み込みすべきだ。
Goo.gl については、ArchiveTeamプロジェクト[1]と協力してみる価値がある。
「URL短縮は本当にひどいアイデアだった」[2]
[1] https://wiki.archiveteam.org/index.php/Goo.gl
[2] https://wiki.archiveteam.org/index.php/URLTeam
そのため、Compiler ExplorerのURLもかなり多く、あるいは全部持っている可能性が高く、連絡してみるのがよさそうだ。
URLが永遠に続くというのは美しい夢だったが、現実にはURLの99%は永遠ではなさそうだ。
勝ち目のない戦いを続けるより、インフラは永続的ではないという前提の上に技術を作るべきなのかもしれない。
その通り。そして、URL短縮サービスをインフラとして使わないことも必要だ。
URN は、モノの同一性と場所を分離することでこの問題を解決しようとしたものだった。
しかし広く使われることはなく、その後リンク短縮サービスがそのアイデアをひどい形で再実装した。
https://en.m.wikipedia.org/wiki/Uniform_Resource_Name
ドメイン名は頻繁に所有者が変わり、永遠であるべきURLも、時間が経つと悪意あるフィッシングリンクに変わることがある。
URLはネットワーク上のリソースの場所を識別するものであって、リソースそのものを識別するものではないため、永続的または一意である必要はない。
だから名前も「uniform resource locator」なのだ。
この問題は1997年にはすでに認識されており、そのため Digital Object Identifier が作られた。
リンク短縮サービスをデータベースのように濫用しておいて、後になって元の参照を失い、インターネットのあちこちから貴重なリンクを回収しなければならないというのは、どこか詩的だ。
本当に濫用しているのは、短縮サービスを使って詐欺、スパム、違法ウェブサイトを共通ドメインの背後に隠し、あちこちにばらまく人たちだ。
データベースとして使っていたのは短縮URLではなく、自分たちのURL、つまりコンパイラの状態を含んでいた部分に見える。
https://killedbygoogle.com/
「Google Go Links (2010–2021)」
「約4年前に終了。Google Short Linksとしても知られ、URL短縮サービスだった。Google Workspace顧客向けのカスタムドメインにも対応していた。約11年続いたサービスだった」
しかし、既存のリンクまで切ることははるかに悪質な行為だ。特にGoogleが自社アプリ内部向けには、今も何らかの形で維持しているならなおさらだ。
Googleが読み取り専用版まで終了するほど、それが手間をかける価値のあるものだという点には少し驚く。
オンラインに残っている非公開リンクのリダイレクトによる法的リスクを懸念しているのでなければ、だが。
正直に言えば、費用が些細でも依然として純コストなので、好感度や過去の約束は脇に置いて、単に切り捨てている可能性も同じくらいありそうだ。
「この記事は人間が書きましたが、リンクの提案と文法チェックはLLMが行いました」
今日こうしたLLM利用の告知を見たのは2回目だ。新しい流行が始まるのを見ているようだ。
内容が自立していればそれで十分だ。内容がゴミなら、それがAI製のゴミなのか人間製のゴミなのかがなぜ重要なのか。
誰かが告知を求めたり知りたがったりする唯一の理由は、自分で内容の品質を判断できず、AI生成かどうかを低品質の代理指標として使っているからだ
言いにくいが、非常に資金力のある財団が関与しない限り、Compiler Explorerと godbolt.org も永遠ではないだろう
その頃には、すべての情報が487京個のパラメータを持つ万物モデルの中に蒸留されているかもしれない
今のところはかなりうまくやってきた。今週で13年目になる
成長が続き、現在のスポンサーが全員離れると仮定しても、1年ちょっと持ちこたえられる資金はある
ただし財団のようなものは考えている。単一障害点は資金ではなく「私」だ
その通りだが、少なくとも今や Compiler Explorer のリンクは、Compiler Explorer が消える時に切れるのであって、その前には切れない
長く生き残る価値が大きい Compiler Explorer のリンクは、バグレポートにあるものだと思う
便宜上、バグレポートに Compiler Explorer をリンクすることはあるが、レポート自体にもコードを入れ、バグを再現する際に使ったコンパイラとバージョンも明記している
Compiler Explorer が近いうちに消えるとは思っていないが、こうしてバグレポートを自己完結的にしておけば、その場合にも守られる
無隠蔽定理のおかげで、情報は永遠に残るだろう ;)
Google 内部の誰かに、データベースを照会して godbolt.org へ向かう短縮リンクをすべて探してもらう方法はおそらくないだろう
ドメイン名を維持するにはお金がかかるのに、URL がどうやって永遠に続くのか分からない
URLの死が良いことなのかもしれない、とも思う。人類は良いものを残そうと特別に努力し、それ以外は歴史のガベージコレクションに入る
歴史家はむしろ、歴史の中のゴミがもっと多いことを望むだろう
保存する価値があると考えられた部分だけでなく、「本当の」生活についてより多くの洞察を得られるからだ
タイムトラベルができるなら、デジタル媒体が劣化して多くの情報が痕跡もなく消えていく私たちの時代を、千年後の歴史家たちがどう振り返るのかを見るのは興味深そうだ
同意する。以前ここに関連する考えを書いた: https://boehs.org/node/internet-evanescence