Compiler Explorer और हमेशा कायम रहने वाले URL का वादा

 (xania.org)
1 पॉइंट द्वारा GN⁺ 2025-05-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Compiler Explorer ने शुरुआत में सभी state को सीधे URL में store करने का तरीका अपनाया था
  • URL बहुत लंबे हो जाने पर Google की goo.gl short URL service लाई गई, लेकिन इससे कई redirects वाली जटिल संरचना बन गई
  • 2018 से URL length limit और maintenance की कठिनाइयों के कारण अपनी S3 और DynamoDB आधारित storage संरचना पर स्विच किया गया
  • लेकिन Google अगस्त 2025 में goo.gl service बंद कर रहा है, इसलिए पुराने short links की स्थायित्व अब खुद संभालनी होगी
  • अब तक 12,000 से ज़्यादा legacy links को बचाया जा चुका है, जो programming knowledge preservation और sustainable service operation के महत्व को दिखाता है

Compiler Explorer links की स्थायी गारंटी और इतिहास

शुरुआती डिज़ाइन और goo.gl अपनाने की पृष्ठभूमि

  • 2012 में, Compiler Explorer ने सभी compiler state को सीधे URL में encode करने वाली संरचना अपनाई
  • state information बढ़ने के साथ URL के अत्यधिक लंबे हो जाने की समस्या सामने आई
  • URL को छोटा बनाने के लिए 2014 में Google की goo.gl shortener service लागू की गई
    • goo.gl/abc123 फ़ॉर्मैट के short links दिए जाते थे, और क्लिक करने पर मूल लंबे URL पर redirect होकर state restore होती थी
  • Stack Overflow द्वारा short links पर रोक (2016) लगाए जाने से इस पुराने तरीके पर प्रतिबंध आ गया
    • malicious links छिपाने के जोखिम की वजह से सभी goo.gl आधारित links प्रभावित हुए
  • user data store न करने की इच्छा के कारण अस्थायी उपाय के रूप में godbolt.org/g/abc123 फ़ॉर्मैट का अपना path बनाया गया
    • godbolt.org/g/abc123 पर जाने पर फिर goo.gl/abc123 पर redirect होता था
    • इस प्रक्रिया के बाद अंत में वापस लंबे godbolt.org URL पर पहुँचा जाता था
    • कई redirects के कारण संरचना जटिल हो गई
  • बाद में Google API के इस्तेमाल से redirect प्रक्रिया कुछ हद तक सरल की गई

अपनी storage संरचना और link management

  • 2018 से URL length limit और data compression की असुविधा बार-बार समस्या बनने लगी
  • S3 और DynamoDB का उपयोग करने वाली अपनी storage संरचना लागू की गई
    • input values को hash करके JSON document के रूप में S3 में store किया गया
    • short link (godbolt.org/z/hashbit) पर पहुँचने पर DynamoDB में mapping lookup की जाती है
    • अगर hash value में गाली या अन्य अनुपयुक्त शब्द आ जाएँ, तो random element जोड़कर उसे bypass करने वाली check feature लागू की गई
    • hash-based links की अनुपयुक्तता की समस्या का समाधान किया गया और इससे जुड़े bugs का अनुभव भी हुआ (उदाहरण: issue #1297)
  • आज भी godbolt.org/g/abc123 address format supported है
  • Google की आधिकारिक घोषणा के बावजूद goo.gl service read-only mode में जा चुकी है, और अगस्त 2025 में पूरी तरह बंद होने वाली है
  • goo.gl आधारित short links को आगे interpret नहीं किया जा सकेगा
  • godbolt.org/g/abc123 फ़ॉर्मैट को सीधे प्रबंधन के जरिए लंबी उम्र दी जा सकती है, इसलिए इस link structure के लिए संगठित rescue work चलाया गया

legacy links का बड़े पैमाने पर संग्रह और archiving

  • हाल में सभी संभावित sources (search, data dumps, web logs आदि) से legacy links को crawl करके database में इकट्ठा किया गया
    • Google Web Search API
    • GitHub API
    • अपने server logs
    • archive.org का Stack Overflow data dump
    • Archive.org के saved webpage data
  • लगभग 12,298 short links सफलतापूर्वक recover किए गए
  • अंदरूनी तौर पर अब goo.gl की जगह अपनी link database का उपयोग शुरू कर दिया गया है (संबंधित PR: #7724)
  • आगे भी अब तक न मिले godbolt.org/g/abc123 links को लगातार खोजकर सुरक्षित किया जाएगा
  • अगर community के पास अब भी ऐसे links हैं जो register नहीं हुए, तो सीधे उन्हें खोलें या admin को बताकर database को और पूरा करने में मदद करें

project philosophy और infrastructure ownership का महत्व

  • इस मामले ने फिर दिखाया कि महत्वपूर्ण infrastructure को बाहरी service (जैसे Google) की स्थायित्व पर छोड़ देने का जोखिम कितना बड़ा है
  • short links management और backup structure अस्थायी उपाय थे, और पूरी तरह permanent URL का वादा करने के लिए पूरी service को खुद manage करना ज़रूरी है
  • digital archaeology की तरह पुराने legacy links को बचाने की प्रक्रिया में यह समझ आया कि हर link किसी के knowledge sharing, सवाल, या concept explanation का निशान है
  • यह storage और preservation का काम programming community के historical archiving से भी सीधे जुड़ा है
  • अगर आपको कोई पुराना Compiler Explorer link मिले, तो अभी भी उसे एक बार खोलकर देखना internet knowledge preservation में योगदान हो सकता है
  • इस बार third-party नहीं, बल्कि सीधे अपने control वाले infrastructure पर निर्भर होकर स्थायित्व के वादे को निभाया जा सकता है

Disclaimer

  • यह लेख इंसान द्वारा लिखा गया है, और link recommendation तथा grammar checking की प्रक्रिया में LLM का उपयोग किया गया

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

1 टिप्पणियां

 
GN⁺ 2025-05-30
Hacker News टिप्पणियाँ
  • 2010 से पहले यह मान लेना लगभग स्वाभाविक लगता था कि लिंक हमेशा के लिए बने रहेंगे, इसलिए मैं ब्राउज़र के bookmark फीचर का सक्रिय रूप से इस्तेमाल करता था, लेकिन समय के साथ मैंने देखा कि बहुत-से bookmark linkrot के कारण व्यावहारिक रूप से बेकार हो गए, उसके बाद मैंने वेबपेज को PDF के रूप में सहेजने की आदत डाल ली, और Reader view आम होने के बाद मैं Reader view से सामग्री कॉपी करके उसे RTF फ़ाइल के रूप में सहेजने लगा
    • मैं अपने द्वारा देखे जाने वाले हर पेज को archive करने के लिए SingleFile extension का उपयोग करता हूँ, इसे install और configure करना काफ़ी आसान है, लेकिन यह काफ़ी storage space लेता है, इस बात का ध्यान रखना चाहिए; उदाहरण के तौर पर, मेरी webpage archive directory 1.1TB तक पहुँच गई है SingleFile GitHub लिंक
    • आधिकारिक Web Archive browser extension install करने पर आप इसे इस तरह सेट कर सकते हैं कि यह आपके द्वारा देखे गए हर पेज को अपने-आप archive करे
    • मेरा तरीका यह है कि महत्वपूर्ण जानकारी, या कम-से-कम उसे कहाँ ढूँढना है, यह याद रखूँ; अभी तक ज़िंदा हूँ, तो यह तरीका किसी हद तक काम करता दिखता है
    • सोच रहा हूँ कि क्या कोई browser extension है जो लिंक timeout होने पर अपने-आप web.archive.org पर भेज दे
    • WARC format को WebRecorder के साथ इस्तेमाल करने का एक तरीका है WARC जानकारी, WebRecorder
  • ArchiveTeam के Goo.gl प्रोजेक्ट के साथ सहयोग करना एक क़ीमती काम हो सकता है प्रोजेक्ट की विस्तृत जानकारी, URL shortening सचमुच अब तक के सबसे ख़राब विचारों में से एक था URLTeam विवरण
    • उस प्रोजेक्ट की live status के मुताबिक, 42.5 अरब goo.gl URL में से 7.5 अरब खोजे जा चुके हैं live status लिंक
    • शायद ArchiveTeam ने 'ज्ञात' लिंक इकट्ठा करने के बजाय Goo.gl short URL को brute-force किया होगा, और संभव है कि Compiler Explorer के ज़्यादातर या सभी URL उनके data में शामिल हों, इसलिए उनसे संपर्क करना अच्छा विचार हो सकता है
  • URL का हमेशा बने रहना एक आदर्शवादी सपना था, लेकिन वास्तविकता में 99% URL स्थायी नहीं होते, इसलिए एक हारी हुई लड़ाई लड़ते रहने के बजाय शायद यह मानकर तकनीक बनानी चाहिए कि infrastructure स्थायी नहीं है
    • यह मानकर तकनीक बनाना सही दिशा है कि infrastructure स्थायी नहीं है, और short URL service को infrastructure की तरह इस्तेमाल करने से भी बचना चाहिए
    • URN(Uniform Resource Name) एक ऐसी प्रणाली थी जिसे location से स्वतंत्र रूप से resource की पहचान देने के लिए बनाया गया था, लेकिन यह लोकप्रिय नहीं हो सकी, और short URL services ने भी इस विचार को ठीक से लागू किए बिना बस कुछ-कुछ वैसा ही करने की कोशिश की URN Wikipedia विवरण
    • domain name का मालिक अक्सर बदल जाता है, और जो URL स्थायी लगते हैं वे भी समय के साथ malicious phishing link में बदल सकते हैं
    • URL नेटवर्क पर केवल resource की location की पहचान करता है, resource की नहीं, इसलिए उसका स्थायी या अद्वितीय होना ज़रूरी नहीं है; इसी वजह से उसका नाम 'Uniform Resource Locator' है; इसी समस्या को पहचानते हुए 1997 में Digital Object Identifier का आविष्कार किया गया
  • short link services का database की तरह दुरुपयोग करना, और फिर बाद में उन क़ीमती लिंक को इंटरनेट के कोनों में दोबारा ढूँढना पड़े, इसमें कुछ काव्यात्मक-सा लगता है
    • URL shortening का मूल उद्देश्य लंबे URL को छोटा करना था; असली समस्या तो वे लोग हैं जो spam, fraud और illegal sites को छिपाने के लिए इन domains का दुरुपयोग करते हैं
    • उन्होंने भी शायद shortener का इस्तेमाल सिर्फ़ URL को compress करने के लिए किया था; असल में उनके URL ही compiler state को 'database' की तरह अपने भीतर रख रहे थे
  • https://killedbygoogle.com/, Google Go Links(2010~2021) Google की URL shortening service थी जो लगभग 11 साल चली और 4 साल पहले बंद हो गई; Google Workspace ग्राहक custom domain भी इस्तेमाल कर सकते थे
    • सेवा बंद करके नए short URL बनाना रोक देना ("minting new ones") मुझे बहुत गंभीर समस्या नहीं लगता, लेकिन पहले से बने URL को भी बंद कर देना कहीं ज़्यादा अनुचित है, ख़ासकर जब Google अब भी अंदरूनी तौर पर कुछ apps में यह सुविधा इस्तेमाल कर रहा है
  • 'यह लेख इंसान ने लिखा है, लेकिन link suggestions और grammar check LLM ने किया'—यह पंक्ति दूसरी सबसे ज़्यादा ध्यान खींचने वाली लगी, जैसे किसी नए trend की शुरुआत देख रहे हों
    • यह दिलचस्प है कि लोग अब ऐसी सूचना-पंक्ति जोड़ने की ज़रूरत महसूस करते हैं
    • मुझे तो ऐसी सूचना-पंक्ति की कोई ज़रूरत बिल्कुल महसूस नहीं होती; अगर content खुद अपने आप को साबित करता है तो वही काफ़ी है, और अगर content की quality खराब है, तो वह AI-generated हो या इंसान द्वारा बनाया गया, इससे फ़र्क नहीं पड़ता; जो लोग ऐसी सूचना चाहते हैं, वे शायद स्वयं content का आकलन करने की क्षमता के बजाय AI-generated content को कम गुणवत्ता वाला मानकर एक तरह के proxy judgment tool की तरह इस्तेमाल करना चाहते हैं
  • यह थोड़ा हैरान करने वाला है कि Google read-only version तक को भी बंद करना चाहता है; सोचता हूँ कि कहीं private link redirection चालू छोड़ने से जुड़े किसी legal risk की चिंता तो नहीं है
    • अंदर की सटीक स्थिति तो नहीं पता, लेकिन हो सकता है कि वे किसी पुराने या security-vulnerable library या runtime पर निर्भर service को बंद करना चाहते हों; और सच तो यह है कि चाहे ख़र्च छोटा ही क्यों न हो, आख़िरकार cost-cutting के लिए service बंद कर दी जाती है, और कंपनियाँ goodwill या पुराने वादों जैसी चीज़ों की ज़्यादा परवाह नहीं करतीं
  • सोच रहा हूँ कि क्या Google के किसी कर्मचारी से कहकर database से सिर्फ़ वे short URL निकलवाने का कोई तरीका हो सकता है जो godbolt.org पर redirect होते हैं
  • सच कहूँ तो, जब तक कोई पर्याप्त रूप से funded foundation बीच में न आए, Compiler Explorer और godbolt.org भी एक दिन स्थायी नहीं रहेंगे; शायद कभी ऐसा समय आए जब सारी जानकारी बहुत बड़े parameters वाले किसी विशाल model में abstract होकर समा जाए
    • अभी तक हमने चीज़ों को काफ़ी अच्छी तरह चलाया है; इस हफ़्ते 13वीं सालगिरह है, और अगर सभी sponsors समर्थन बंद भी कर दें, तो भी हमारे पास लगभग एक साल से कुछ ज़्यादा चलाने भर का पैसा जमा है; हाल में foundation बनाने जैसी बातों पर भी विचार कर रहे हैं; असली कमज़ोरी funding की कमी नहीं, बल्कि यह है कि एक व्यक्ति (मैं) single point of failure हूँ
    • सही बात है, अब Compiler Explorer के लिंक शायद तभी बंद होंगे जब Compiler Explorer खुद ही गायब होगा; उससे पहले लिंक बचे रहने चाहिए; ख़ासकर bug report में डाले गए Compiler Explorer लिंक बहुत क़ीमती लगते हैं; मैं भी ऐसे लिंक के साथ code को सीधे report में शामिल करता हूँ, और यह भी लिखता हूँ कि कौन-सा compiler और version इस्तेमाल किया गया; मुझे नहीं लगता Compiler Explorer जल्द गायब होने वाला है, लेकिन bug report को इस तरह self-contained बनाकर रखना किसी अप्रत्याशित ग़ायब होने की स्थिति के लिए अच्छी तैयारी है
    • no-hiding theorem की वह मज़ाकिया बात याद आती है कि जानकारी हमेशा जीवित रहती है
  • domain बनाए रखने में भी पैसा लगता है, इसलिए समझ नहीं आता कि URL कैसे हमेशा के लिए बने रह सकते हैं; कभी-कभी लगता है कि URL का मिट जाना शायद सकारात्मक भी हो सकता है; इंसानियत केवल क़ीमती जानकारी को विशेष रूप से बचाती है, बाकी चीज़ें स्वाभाविक रूप से इतिहास में खो जाती हैं
    • लेकिन इतिहासकार तो ऐसे 'कचरा' data को भी ज़्यादा से ज़्यादा चाहते हैं, क्योंकि उसी से वे उस समय के वास्तविक जीवन और संदर्भ को बेहतर समझ सकते हैं; अगर टाइम मशीन होती, तो सोचता हूँ कि हज़ार साल बाद के इतिहासकार इस दौर को कैसे देखते, जब digital media के मिटने के साथ अधिकांश जानकारी भी खो गई
    • मैं भी इस बात से सहमत हूँ कि URL का मिटना कुछ मायनों में अच्छा हो सकता है; इस पर मैंने एक लेख लिखा है इंटरनेट की क्षणभंगुरता पर