Compiler Explorer und das Versprechen dauerhaft gültiger URLs

• Compiler Explorer nutzte anfangs einen Ansatz, bei dem der gesamte Zustand direkt in der URL gespeichert wurde
• Als die URLs zu lang wurden, wurde Googles URL-Kürzungsdienst goo.gl eingeführt, was eine komplexe Struktur mit mehreren Redirects verursachte
• Ab 2018 wurde wegen der URL-Längenbegrenzung und der schwierigen Wartung auf eine eigene S3- und DynamoDB-basierte Speicherung umgestellt
• Da Google den goo.gl-Dienst im August 2025 einstellt, muss die Dauerhaftigkeit alter Kurzlinks nun selbst verwaltet werden
• Bis heute wurden mehr als 12.000 Legacy-Links gerettet, was die Bedeutung von Wissensbewahrung in der Programmierung und nachhaltigem Servicebetrieb zeigt

---

Die dauerhafte Garantie für Compiler-Explorer-Links und ihre Geschichte

Frühes Design und warum goo.gl eingeführt wurde

• 2012 führte Compiler Explorer eine Struktur ein, bei der der gesamte Compiler-Zustand direkt in die URL kodiert wurde
• Je mehr Zustandsinformationen hinzukamen, desto länger wurden die URLs und desto problematischer wurde das
• Um die URLs zu verkürzen, wurde 2014 Googles Kürzungsdienst goo.gl eingesetzt
  • Kurzlinks im Format goo.gl/abc123 wurden bereitgestellt; beim Anklicken erfolgte ein Redirect auf die ursprüngliche lange URL, woraufhin der Zustand wiederhergestellt wurde
• Als Stack Overflow 2016 die Nutzung von Kurzlinks untersagte, entstanden Einschränkungen für dieses Verfahren
  • Wegen des Risikos, bösartige Links zu verschleiern, waren alle auf goo.gl basierenden Links betroffen
• Da man keine Nutzerdaten speichern wollte, wurde als Zwischenlösung ein eigener Pfad im Format godbolt.org/g/abc123 geschaffen
  • Beim Aufruf von godbolt.org/g/abc123 wurde erneut auf goo.gl/abc123 weitergeleitet
  • Danach ging es letztlich wieder zurück zu einer langen godbolt.org-URL
  • Durch diese mehrfachen Redirects wurde die Struktur unnötig kompliziert
• Später wurde der Ablauf durch die Nutzung von Googles API teilweise vereinfacht

Einführung eines eigenen Speichers und Link-Verwaltung

• Ab 2018 wurden die Grenzen der URL-Länge und die Unbequemlichkeit der Datenkomprimierung immer häufiger zum Problem
• Es wurde eine eigene Speicherstruktur auf Basis von S3 und DynamoDB implementiert
  • Eingabewerte werden gehasht und als JSON-Dokumente in S3 gespeichert
  • Beim Aufruf eines Kurzlinks (godbolt.org/z/hashbit) wird die Zuordnung in DynamoDB nachgeschlagen
  • Falls der Hashwert Schimpfwörter oder andere unangemessene Begriffe enthält, wird durch ein zusätzliches Zufallselement ausgewichen
  • Dafür wurde eine Prüffunktion implementiert, die Probleme mit ungeeigneten Hash-basierten Links behebt; dabei gab es auch entsprechende Bugs (z. B. issue #1297)
• Das Adressformat godbolt.org/g/abc123 wird weiterhin unterstützt
• Trotz offizieller Hinweise von Google wurde der goo.gl-Dienst in einen schreibgeschützten Zustand versetzt und soll im August 2025 vollständig eingestellt werden
• Goo.gl-basierte Kurzlinks werden dann nicht mehr auflösbar sein
• Die Form godbolt.org/g/abc123 kann jedoch durch direkte Eigenverwaltung weiter am Leben gehalten werden, weshalb für diese Linkstruktur eine systematische Rettungsaktion läuft

Massensammlung und Archivierung von Legacy-Links

• Kürzlich wurden Legacy-Links aus allen verfügbaren Quellen gecrawlt und in einer Datenbank erfasst (Suche, Datendumps, Weblogs usw.)
  • Google Web Search API
  • GitHub API
  • eigene Server-Logs
  • Stack-Overflow-Datendumps von archive.org
  • archivierte Webseiten von Archive.org
• Etwa 12.298 Kurzlinks konnten erfolgreich wiederhergestellt werden
• Intern wird nun statt goo.gl eine eigene Link-Datenbank verwendet (zugehöriger PR: #7724)
• Auch künftig sollen bislang unentdeckte Links im Format godbolt.org/g/abc123 fortlaufend gesammelt und gesichert werden
• Falls es in der Community noch nicht registrierte Links gibt, soll man sie direkt aufrufen oder den Administrator informieren, damit die Datenbank ergänzt werden kann

Projektphilosophie und die Bedeutung des Besitzes der Infrastruktur

• Dieser Fall zeigt das Risiko, wichtige Infrastruktur allein von der Beständigkeit externer Dienste (z. B. Google) abhängig zu machen
• Die Verwaltung von Kurzlinks und die Backup-Struktur waren nur Übergangslösungen; wer wirklich dauerhaft gültige URLs versprechen will, muss den gesamten Dienst selbst kontrollieren
• Bei der Rettung alter Legacy-Links wurde wie bei digitaler Archäologie deutlich, dass jeder einzelne Link eine Spur von Wissensaustausch, Fragen oder Begriffserklärungen einer Person ist
• Dieses Speichern und Bewahren steht somit auch in direktem Zusammenhang mit der Archivierung der Geschichte der Programmier-Community
• Wer einen alten Compiler-Explorer-Link entdeckt, kann durch einen Klick selbst jetzt noch zur Bewahrung von Wissen im Internet beitragen
• Diesmal kann das Versprechen dauerhafter Verfügbarkeit eingehalten werden, weil man sich auf eigene statt auf fremde Infrastruktur stützt

Disclaimer

• Dieser Text wurde von einem Menschen verfasst; für Link-Empfehlungen und die Grammatikprüfung wurden LLMs verwendet

[GN⁺]

Hacker-News-Kommentare

• Vor 2010 fühlte sich die Annahme, dass Links für immer bestehen, selbstverständlich an. Deshalb habe ich die Lesezeichenfunktion des Browsers aktiv genutzt. Mit der Zeit habe ich aber erlebt, dass viele Lesezeichen durch Linkrot praktisch unbrauchbar wurden. Danach habe ich mir angewöhnt, Webseiten als PDF zu speichern. Als die Reader View populär wurde, bin ich dazu übergegangen, Inhalte aus der Reader View zu kopieren und als RTF-Datei zu speichern.
  • Ich nutze die Erweiterung SingleFile, um alle Seiten zu archivieren, die ich besuche. Die Einrichtung ist recht einfach, aber man sollte beachten, dass sie ziemlich viel Speicherplatz benötigt. Mein Webarchiv-Verzeichnis ist zum Beispiel auf 1,1 TB angewachsen. SingleFile GitHub-Link
  • Wenn man die offizielle Web-Archive-Browser-Erweiterung installiert, kann man einstellen, dass alle besuchten Seiten automatisch archiviert werden.
  • Meine Methode ist, mir wichtige Informationen oder zumindest zu merken, wo ich sie finden kann. Ich lebe noch, also funktioniert die Methode bisher wohl ganz gut.
  • Ich frage mich, ob es eine Browser-Erweiterung gibt, die bei einem Timeout eines Links automatisch zu web.archive.org weiterleitet.
  • Es gibt auch die Möglichkeit, das WARC-Format zusammen mit WebRecorder zu verwenden. WARC-Informationen, WebRecorder
• Es könnte sinnvoll sein, mit dem Goo.gl-Projekt von ArchiveTeam zusammenzuarbeiten. Projektdetails URL-Verkürzung war wirklich eine der schlechtesten Ideen überhaupt. URLTeam-Erklärung
  • Laut dem Live-Status des Projekts wurden 7,5 Milliarden der 42,5 Milliarden goo.gl-URLs bereits gefunden. Link zum Live-Status
  • ArchiveTeam hat vermutlich nicht mit „bekannten“ Links gearbeitet, sondern Goo.gl-Kurz-URLs per Brute Force ermittelt. Ich würde vermuten, dass die meisten oder sogar alle URLs von Compiler Explorer in ihren Daten enthalten sind. Deshalb scheint es eine gute Idee zu sein, Kontakt aufzunehmen.
• Dass URLs für immer bestehen, war ein idealistischer Traum. Realistisch gesehen sind 99 % der URLs nicht dauerhaft. Statt weiter einen verlorenen Kampf zu führen, sollte man Technik vielleicht unter der Annahme bauen, dass Infrastruktur nicht dauerhaft ist.
  • Technik unter der Annahme zu entwickeln, dass Infrastruktur nicht dauerhaft ist, ist der richtige Weg. Und ich denke auch, dass man URL-Shortener nicht wie Infrastruktur verwenden sollte.
  • URN (Uniform Resource Name) ist ein System, das entwickelt wurde, um Ressourcen unabhängig von ihrem Ort eine Identität zu geben. Es hat sich jedoch nicht durchgesetzt; stattdessen haben URL-Shortener so etwas Ähnliches versucht, ohne das Konzept wirklich sauber umzusetzen. URN-Wikipedia-Erklärung
  • Domainnamen wechseln oft den Besitzer, und selbst URLs, die dauerhaft wirken, können sich mit der Zeit in bösartige Phishing-Links verwandeln.
  • Eine URL identifiziert im Netzwerk nur den Ort einer Ressource, nicht die Ressource selbst. Deshalb muss sie weder dauerhaft noch eindeutig sein. Daher auch der Name „Uniform Resource Locator“. In Reaktion auf dieses Problem wurde 1997 der Digital Object Identifier erfunden.
• Es hat etwas Poetisches, einen Link-Shortener wie eine Datenbank zu missbrauchen und später kostbare Links wieder in allen Ecken des Internets zusammensuchen zu müssen.
  • Der eigentliche Zweck von URL-Verkürzung ist es, lange URLs kurz zu machen. Das eigentliche Problem sind eher Leute, die Domains missbrauchen, um über Kurz-URLs Spam, Betrug und illegale Websites zu verbergen.
  • Sie scheinen den Dienst auch einfach benutzt zu haben, um die URL zu komprimieren. Ihre eigentlichen URLs selbst enthielten bereits den Compiler-Zustand gewissermaßen als „Datenbank“.
• https://killedbygoogle.com/, Google Go Links (2010–2021) war Googles URL-Verkürzungsdienst, der etwa 11 Jahre lang betrieben und vor 4 Jahren eingestellt wurde. Google-Workspace-Kunden konnten auch eigene Domains verwenden.
  • Dass der Dienst beendet wurde, indem keine neuen Kurz-URLs mehr erstellt werden konnten („minting new ones“), halte ich nicht für besonders schwerwiegend. Viel unfairer ist es, auch bereits existierende URLs abzuschalten. Vor allem, weil Google diese Funktion intern in einigen Apps offenbar weiterhin nutzt.
• Der Satz „Dieser Beitrag wurde von einem Menschen geschrieben, aber Linkvorschläge und Grammatikprüfung kamen von einem LLM“ ist mir als das Zweitauffälligste ins Auge gefallen. Es fühlt sich an, als würde man den Beginn eines neuen Trends sehen.
  • Interessant ist die Realität, in der Menschen das Gefühl haben, solche Hinweise überhaupt hinzufügen zu müssen.
  • Ich persönlich sehe überhaupt keine Notwendigkeit für solche Hinweise. Wenn der Inhalt für sich selbst spricht, reicht das aus. Falls die Qualität des Inhalts schlecht ist, spielt es keine Rolle, ob er von einer KI oder von einem Menschen stammt. Menschen, die solche Hinweise wollen, scheinen sie als eine Art stellvertretende Bewertungsheuristik zu verwenden, weil sie Inhalte nicht selbst beurteilen können und KI-generierte Inhalte pauschal als minderwertig ansehen.
• Es überrascht mich, dass Google sogar die schreibgeschützte Version abschalten will. Ich frage mich, ob sie wegen beibehaltener Weiterleitungen für private Links rechtliche Risiken befürchten.
  • Ich kenne die genauen internen Gründe natürlich nicht, aber vielleicht wollen sie einen laufenden Dienst abschalten, weil er von veralteten oder unsicheren Bibliotheken oder Laufzeitumgebungen abhängt. Selbst wenn die Kosten gering sind, läuft es am Ende wohl auf Kostensenkung hinaus, und es entsteht der Eindruck, dass ihnen unternehmerischer Goodwill oder frühere Zusagen egal sind.
• Ich frage mich, ob es wirklich gar keinen Weg gibt, einen Google-Mitarbeiter darum zu bitten, nur die Kurz-URLs, die auf godbolt.org weiterleiten, aus der Datenbank zu extrahieren.
• Ehrlich gesagt sind auch Compiler Explorer und godbolt.org wohl irgendwann nicht mehr ewig, sofern keine ausreichend gut finanzierte Stiftung eingreift. Vielleicht wird eines Tages ohnehin alle Information abstrahiert und in riesigen Modellen mit gewaltigen Parametern gespeichert.
  • Bisher haben wir uns gut gehalten. Diese Woche ist unser 13. Jahrestag, und selbst wenn alle Sponsoren ihre Unterstützung einstellen würden, haben wir genug Mittel angespart, um noch etwas mehr als ein Jahr weiterzumachen. In letzter Zeit denken wir auch über die Gründung einer Stiftung nach. Die eigentliche Schwachstelle ist nicht fehlendes Geld, sondern dass eine einzelne Person, nämlich ich, ein Single Point of Failure bin.
  • Das stimmt. Der Zeitpunkt, an dem Compiler-Explorer-Links ausfallen, wird jetzt wohl wirklich erst dann kommen, wenn Compiler Explorer selbst verschwindet. Bis dahin bleiben die Links bestehen. Gerade Compiler-Explorer-Links in Bugreports halte ich für sehr wertvoll. Ich selbst füge bei solchen Links den Code auch direkt in den Report ein und schreibe dazu, welchen Compiler und welche Version ich verwendet habe. Ich glaube nicht, dass Compiler Explorer bald verschwinden wird, aber wenn man Bugreports so in sich selbst vollständig macht, ist man auch gegen ein unerwartetes Verschwinden abgesichert.
  • Das erinnert mich an den Witz, dass nach dem No-Hiding-Theorem Information für immer überlebt.
• Schon die Aufrechterhaltung einer Domain kostet Geld, deshalb verstehe ich nicht, wie URLs für immer bestehen könnten. Ich frage mich, ob das Verschwinden von URLs nicht sogar etwas Positives haben könnte. Die Menschheit bewahrt nur besonders wertvolle Informationen gezielt auf, während der Rest ganz natürlich in der Geschichte verschwindet.
  • Historiker wollen jedoch sogar mehr von solchen „Müll“-Daten, weil sich damit das tatsächliche Leben und der Kontext einer Zeit besser verstehen lassen. Wenn ich in einer Zeitmaschine reisen könnte, würde mich interessieren, wie Historiker in tausend Jahren auf diese Epoche blicken werden, in der mit dem Verschwinden digitaler Medien der Großteil der Informationen verloren ging.
  • Ich stimme ebenfalls zu, dass das Verschwinden von URLs auch etwas Gutes haben kann. Ich habe dazu einen Text geschrieben. Über die Flüchtigkeit des Internets