Compiler Explorer और “हमेशा बने रहने वाले URL” के वादे

 (xania.org)
1 पॉइंट द्वारा GN⁺ 2025-05-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Compiler Explorer ने 2012 से स्टोरेज का तरीका बदलते हुए साझा लिंक को लंबे समय तक जीवित रखने की कोशिश की, लेकिन goo.gl के बंद होने से पुराने godbolt.org/g/abc123 लिंक को सुरक्षित रखना अब ज़रूरी हो गया है
  • शुरुआत में पूरा compiler state URL में रखा जाता था, 2014 में Google URL shortener जोड़ा गया, और 2016 में Stack Overflow द्वारा short URL पर रोक के बाद godbolt.org/g/abc123 जैसे workaround लिंक बनाए गए
  • 2018 से, जब URL लंबाई की सीमा बड़ी समस्या बन गई, state को S3 में JSON document के रूप में स्टोर करने और छोटे hash व पूरे path की mapping को DynamoDB से मैनेज करने वाली अपनी व्यवस्था अपनाई गई
  • जब Google अगस्त 2025 में goo.gl लिंक बंद करेगा, तब पुराने goo.gl-आधारित लिंक को resolve करना मुश्किल हो जाएगा, इसलिए सार्वजनिक वेब और logs से मिले लगभग 12,000 g लिंक और उनके redirect targets को अपने database में इकट्ठा किया जा रहा है
  • जिन उपयोगकर्ताओं के पास पुराने Compiler Explorer लिंक हैं, अगर वे अभी उन लिंक पर जाएँ तो वे preservation list में शामिल हो सकते हैं; लंबे समय तक टिकने वाला साझा ज्ञान तब अधिक सुरक्षित होता है जब मुख्य infrastructure पर अपना सीधा नियंत्रण हो

Compiler Explorer लिंक स्टोरेज तरीके में बदलाव

  • 2012 में Compiler Explorer की पूरी state को URL के अंदर स्टोर किया जाता था
  • पूरी compiler state को URL में encode करने का तरीका बहुत लंबा हो जाता था और संभालना मुश्किल था, इसलिए मार्च 2014 में Google की goo.gl short URL सेवा का समर्थन जोड़ा गया
  • उस समय short link goo.gl/abc123 के रूप में होता था, और उस पर क्लिक करने से पहले Compiler Explorer साइट के पूरे URL पर redirect होता था, फिर URL के अंदर की state decode की जाती थी

Stack Overflow की रोक के बाद workaround लिंक

  • 2016 में Stack Overflow ने इस कारण link shortening services पर रोक लगा दी कि वे असली destination को छिपा सकती हैं
  • इस कदम का असर Compiler Explorer लिंक पर भी पड़ा, और उस समय user data को सीधे स्टोर करने का इरादा नहीं था
  • workaround यह था कि अंदर से goo.gl का उपयोग जारी रहे, लेकिन उपयोगकर्ताओं को godbolt.org/g/abc123 जैसे लिंक दिए जाएँ
    • abc123 goo.gl का unique ID था
    • /g/abc123 पर जाने से goo.gl/abc123 पर redirect होता था
    • फिर goo.gl state वाले पूरे godbolt.org URL पर redirect करता था
  • बाद में Google API का उपयोग करके कई चरणों वाली redirect chain से बचा गया

2018 में अपने स्टोरेज पर बदलाव

  • 2018 तक URL लंबाई की सीमा और बड़ी समस्या बन गई थी, और URL के अंदर मौजूद data को पहले से compress भी किया जा रहा था
  • Compiler Explorer ने state को सीधे स्टोर करने वाली संरचना अपनाई
    • input का hash बनाया जाता है
    • state को S3 में JSON document के रूप में स्टोर किया जाता है
    • hash के छोटे रूप को godbolt.org/z/hashbit URL के रूप में दिया जाता है
    • DynamoDB में छोटे hash और पूरे path की mapping स्टोर की जाती है
  • short link hash में आपत्तिजनक शब्द तो नहीं आ रहे, इसकी भी जाँच की जाती थी
    • अगर आपत्तिजनक शब्द मिलते, तो document में जानबूझकर अतिरिक्त जानकारी जोड़कर अलग hash बनाया जाता था
    • इस व्यवहार से bug #1297 पैदा हुआ

goo.gl बंद होने से बना preservation संकट

  • Compiler Explorer अभी भी godbolt.org/g/abc123 लिंक को support करता है
  • Google ने कहा था कि पुराने लिंक अपने intended destination पर redirect होते रहेंगे, लेकिन goo.gl कुछ साल पहले read-only हो गया था और अगस्त 2025 में पूरी तरह बंद होने वाला है
  • बंद होने के बाद goo.gl-आधारित लिंक को आगे resolve नहीं किया जा सकेगा
  • असली goo.gl लिंक को Compiler Explorer अपनी तरफ़ से ठीक नहीं कर सकता, लेकिन godbolt.org/g/abc123 लिंक को अपने database के ज़रिए सुरक्षित रखा जा सकता है

पुराने लिंक जुटाना और अपना database

  • पिछले कुछ दिनों से कई सार्वजनिक स्रोतों से पुराने लिंक और उनके redirect target URL इकट्ठा किए जा रहे हैं
  • अब तक लगभग 12,000 लिंक मिले हैं
    • Google web search API
    • GitHub API
    • अपने web logs
    • archive.org का Stack Overflow data dump
    • Archive.org द्वारा सहेजी गई web pages की सूची
  • अंदरूनी तौर पर बदलाव किया गया है ताकि goo.gl की जगह अपने database को प्राथमिकता दी जाए
  • database में अभी तक न मौजूद नए g लिंक पर भी नज़र रखी जा रही है
  • लोकल में sqlite database है, और production में Dynamo का उपयोग होता है

उपयोगकर्ता कैसे मदद कर सकते हैं

  • अगर आपने पुराने godbolt.org/g/abc123 लिंक अलग से संभालकर रखे हैं, तो अभी उन लिंक पर जाना मददगार होगा
  • लिंक पर जाने से वह web logs में दर्ज होगा और बाद में database में जोड़ा जा सकता है
  • नहीं तो अगस्त 2025 के बाद वह लिंक काम नहीं भी कर सकता
  • यह मामला दिखाता है कि अहम infrastructure के लिए third-party services पर निर्भर रहना कितना जोखिमभरा है
  • “हमेशा बने रहने वाले URL” के वादे को निभाने के लिए पूरे stack पर अपना सीधा स्वामित्व होना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-30
Hacker News की राय

  • 2010 से पहले यह मान लेना स्वाभाविक लगता था कि लिंक हमेशा बने रहेंगे, और ब्राउज़र bookmarks का खूब इस्तेमाल किया जाता था
    बाद में पता चला कि मेरे काफी bookmarks link rot की वजह से व्यावहारिक रूप से बेकार हो गए थे, और उसके बाद मैंने webpages को PDF के रूप में print करके save करना शुरू किया
    reader view फीचर काफी भरोसेमंद तरीके से फैल जाने के बाद, तरीका बदलकर reader view की सामग्री copy करके RTF file में save करने वाला हो गया

    • मैं हर visit किए गए page को archive करने के लिए SingleFile extension इस्तेमाल करता/करती हूँ
      setup आसान है, लेकिन ध्यान रहे कि यह disk space काफी खाता है

      $ du -h ~/archive/webpages
      1.1T /home/andrew/archive/webpages

      https://github.com/gildas-lormeau/SingleFile

    • official Web Archive browser extension install करें तो इसे हर visit किए गए page को automatically archive करने के लिए configure किया जा सकता है

    • मेरा solution यह था कि महत्वपूर्ण content को ही याद रखूँ, या कम से कम यह याद रखूँ कि उसे कहाँ ढूँढ़ सकता/सकती हूँ
      अभी तक मरा/मरी नहीं हूँ, तो कह सकते हैं कि यह काम कर रहा है

    • सोचता/सोचती हूँ कि क्या कोई ऐसा browser extension है जो link timeout होने पर automatically web.archive.org पर चला जाए

    • यह सचमुच समझ से बाहर है कि browsers ने अब तक इस एहसास को ध्यान में रखते हुए bookmark feature को ठीक नहीं किया
      हर bookmark को सिर्फ link नहीं, बल्कि rendered page की पूरी copy भी save करनी चाहिए। सिर्फ original source save नहीं करना चाहिए, जो ऐसे dynamic content पर निर्भर हो सकता है जो आगे मौजूद ही न रहे

      खुले हुए tabs के साथ भी यही होना चाहिए। internet connection न होने पर जब मैं किसी tab पर वापस जाऊँ, तो सिर्फ इसलिए network error नहीं देखना चाहता/चाहती कि browser ने मेहरबानी करके उस tab को memory से निकाल दिया था
      ऐसे मामले में, जब तक मैं manually refresh न करूँ, state को network से नहीं बल्कि disk से reload करना चाहिए

  • Goo.gl के लिए ArchiveTeam project[1] के साथ collaborate करना ठीक रहेगा
    “URL shortening सचमुच एक बेहद खराब idea था”[2]

    [1] https://wiki.archiveteam.org/index.php/Goo.gl

    [2] https://wiki.archiveteam.org/index.php/URLTeam

    • अगर मेरी याद सही है, तो ArchiveTeam ‘known’ links follow नहीं कर रहा था, बल्कि Goo.gl short URLs को brute-force कर रहा था
      इसलिए संभावना है कि उनके पास Compiler Explorer URLs में से काफी सारे या सारे ही हों, और उनसे संपर्क करना अच्छा लगेगा
    • उस project का live status देखें तो वे 42 अरब goo.gl URLs scan कर चुके हैं और 7.5 अरब ढूँढ़ चुके हैं: https://tracker.archiveteam.org:1338/status

  • URL हमेशा बने रहेंगे, यह एक खूबसूरत सपना था, लेकिन असलियत में 99% URLs स्थायी नहीं लगते
    लगातार हारती लड़ाई लड़ने के बजाय, शायद हमें तकनीक इस assumption पर बनानी चाहिए कि infrastructure permanent नहीं है

    • सही। और URL shortening services को infrastructure के तौर पर इस्तेमाल न करना भी जरूरी है

    • URN इसी समस्या को solve करने की कोशिश थी—किसी चीज़ की identity और location को अलग करके
      लेकिन इसका व्यापक इस्तेमाल नहीं हुआ, और बाद में link shortening services ने उस idea को बहुत खराब तरीके से फिर से implement किया

      https://en.m.wikipedia.org/wiki/Uniform_Resource_Name

    • domain names के मालिक अक्सर बदलते रहते हैं, और जो URL हमेशा रहना चाहिए था वह भी समय के साथ malicious phishing link में बदल सकता है

    • URL network पर resource की location identify करता है, resource को खुद नहीं; इसलिए उसका permanent या unique होना जरूरी नहीं
      इसी वजह से नाम भी “uniform resource locator” है

      यह समस्या 1997 में ही पहचान ली गई थी, और इसी कारण Digital Object Identifier बनाया गया था

  • link shortening service को database की तरह misuse करने के बाद, बाद में original reference खो देना और internet के अलग-अलग कोनों से valuable links recover करने पड़ना—इसमें कुछ poetic-सा है

    • लंबे URL को छोटा करना URL shortening service का intended use case है
      असल misuse करने वाले वे लोग हैं जो shortening service से scams, spam और illegal websites को common domain के पीछे छिपाकर हर जगह फैलाते हैं
    • क्या उन्होंने बस URL compress करने के लिए link shortening service इस्तेमाल नहीं की थी
      database के रूप में इस्तेमाल short URL को नहीं, बल्कि अपने URL को किया गया लगता है—यानी वह हिस्सा जिसमें compiler state थी

  • https://killedbygoogle.com/

    “Google Go Links (2010–2021)”

    “लगभग 4 साल पहले बंद हुआ। इसे Google Short Links के नाम से भी जाना जाता था, और यह एक URL shortening service थी। Google Workspace customers के लिए custom domains भी support करता था। यह लगभग 11 साल पुरानी service थी”

    • नए links बनाना बंद करने के अर्थ में service को “मारना” कोई बड़ी बात नहीं है और मुश्किल से उल्लेख के लायक है
      लेकिन existing links तक तोड़ देना कहीं ज्यादा खराब कदम है। खासकर अगर Google अपने apps के internal use के लिए अभी भी इसे किसी न किसी रूप में बनाए हुए है

  • थोड़ा आश्चर्य है कि Google को read-only version तक बंद करना इतनी मेहनत के लायक लगा
    जब तक कि वे online बचे हुए private link redirects की वजह से legal risk को लेकर चिंतित न हों

    • बाहर से जानना मुश्किल है, लेकिन संभव है कि यह service ऐसी पुरानी या insecure libraries, runtime, services आदि पर निर्भर हो जिन्हें वे अब चलाना नहीं चाहते
      सच कहूँ तो, cost छोटी भी हो तो भी वह net cost ही है, इसलिए goodwill या पुराने promises को अलग रखकर बस इसे काट देने की संभावना भी उतनी ही लगती है

  • “यह लेख इंसान ने लिखा है, लेकिन link suggestions और grammar checks LLM ने किए हैं”

    आज ऐसा LLM usage disclosure देखने का यह मेरा दूसरा मौका है। लगता है जैसे कोई नया trend शुरू होते देख रहा/रही हूँ

    • यह अजीब है कि लोगों को लगता है कि उन्हें ऐसी disclosure डालनी चाहिए
    • मुझे नहीं लगता कि ऐसी disclosure की कोई जरूरत है
      अगर content अपने दम पर खड़ा हो सकता है, तो वही काफी है। अगर content कचरा है, तो इससे क्या फर्क पड़ता है कि वह AI-generated कचरा है या इंसान-generated कचरा?

किसी को नोटिस चाहिए या वह यह जानना चाहता है, इसकी एकमात्र वजह यह है कि वह खुद सामग्री की गुणवत्ता नहीं परख सकता और AI से बनी है या नहीं को कम गुणवत्ता का proxy indicator मानता है

  • कहना अच्छा नहीं लग रहा, लेकिन जब तक कोई बहुत मजबूत funding वाला foundation शामिल नहीं होता, Compiler Explorer और godbolt.org भी हमेशा के लिए नहीं रहेंगे
    उस समय तक शायद सारी जानकारी 487 क्विंटिलियन parameters वाले किसी universal model में distilled हो चुकी होगी

    • अब तक तो हमने काफी अच्छा किया है। इस हफ्ते 13 साल पूरे हो रहे हैं
      अगर growth जारी रहती है और मौजूदा सारे sponsors हट भी जाते हैं, तो हमारे पास एक साल से थोड़ा ज़्यादा टिके रहने का पैसा है

      हालांकि foundation जैसी चीज़ के बारे में सोच रहा हूँ। single point of failure पैसा नहीं, “मैं” हूँ

    • बात सही है, लेकिन कम से कम अब Compiler Explorer links Compiler Explorer के गायब होने पर टूटेंगे, उससे पहले नहीं
      मेरे हिसाब से लंबे समय तक बचे रहने लायक Compiler Explorer links वे हैं जो bug reports में होते हैं
      सुविधा के लिए bug report में Compiler Explorer को link कर देते हैं, लेकिन report में ही code भी डालते हैं और bug reproduce करने के लिए इस्तेमाल compiler और version भी बताते हैं
      मुझे उम्मीद नहीं कि Compiler Explorer जल्द गायब होगा, लेकिन bug reports को self-contained बनाने से उस स्थिति में भी सुरक्षा रहती है

    • No-hiding theorem की वजह से जानकारी हमेशा बनी रहेगी ;)

  • शायद Google के अंदर किसी से database query करवाकर godbolt.org की ओर जाने वाले सारे short links ढूंढने का कोई तरीका नहीं होगा

  • domain name बनाए रखने में पैसे लगते हैं, इसलिए समझ नहीं आता कि URL हमेशा कैसे टिक सकते हैं
    सोचता हूँ कि क्या URL की मौत अच्छी चीज़ भी हो सकती है। मानवता अच्छी चीज़ों को बचाए रखने की खास कोशिश करती है, और बाकी इतिहास के garbage collection में चला जाता है

    • इतिहासकार तो शायद चाहेंगे कि इतिहास में कचरा और ज़्यादा हो
      क्योंकि इससे सिर्फ उन हिस्सों तक नहीं, जिन्हें बचाने लायक माना गया, बल्कि “असली” जीवन के बारे में भी ज्यादा insight मिलती है

      अगर time travel कर पाता, तो यह देखना दिलचस्प होता कि आज से हजार साल बाद के इतिहासकार हमारे दौर को कैसे देखेंगे, जब digital media सड़ने से बहुत-सी जानकारी बिना निशान के गायब हो चुकी होगी

    • सहमत हूँ। पहले इसी से जुड़े विचार यहाँ लिखे थे: https://boehs.org/node/internet-evanescence