คำมั่นสัญญาของ Compiler Explorer กับ URL ที่คงอยู่ตลอดไป

 (xania.org)
1 คะแนน โดย GN⁺ 2025-05-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Compiler Explorer ในช่วงแรกใช้วิธี เก็บสถานะทั้งหมดไว้ใน URL โดยตรง
  • เมื่อ URL ยาวเกินไป จึงนำ บริการย่อ URL goo.gl ของ Google มาใช้ ซึ่งทำให้โครงสร้างซับซ้อนจากการต้องผ่านรีไดเร็กต์หลายครั้ง
  • ตั้งแต่ปี 2018 ได้เปลี่ยนมาใช้โครงสร้างที่อาศัย สตอเรจของตนเองบน S3 และ DynamoDB เนื่องจากปัญหาข้อจำกัดความยาวของ URL และความยากในการบำรุงรักษา
  • แต่เมื่อ Google จะยุติบริการ goo.gl ในเดือนสิงหาคม 2025 ก็ทำให้ต้องมารับผิดชอบความคงอยู่ของลิงก์ย่อเก่า ๆ ด้วยตนเอง
  • จนถึงตอนนี้ได้ กู้ลิงก์แบบเลกาซี มาแล้วมากกว่า 12,000 รายการ ซึ่งสะท้อนให้เห็นถึงความสำคัญของ การอนุรักษ์ความรู้ด้านการเขียนโปรแกรมและการดำเนินบริการอย่างยั่งยืน

ประวัติและการรับประกันความคงอยู่ของลิงก์ Compiler Explorer

แนวทางออกแบบช่วงแรกและที่มาของการนำ goo.gl มาใช้

  • ในปี 2012 Compiler Explorer ได้นำโครงสร้างที่ เข้ารหัสสถานะของคอมไพเลอร์ทั้งหมดลงใน URL โดยตรง มาใช้
  • เมื่อข้อมูลสถานะมีมากขึ้น ก็เกิดปัญหา URL ยาวเกินไป
  • เพื่อทำให้ URL สั้นลง จึงเริ่มใช้ บริการย่อ URL goo.gl ของ Google ในปี 2014
    • ให้ลิงก์ย่อในรูปแบบ goo.gl/abc123 และเมื่อคลิกก็จะรีไดเร็กต์ไปยัง URL แบบยาวเดิมเพื่อกู้คืนสถานะ
  • Stack Overflow ออกมาตรการห้ามใช้ลิงก์ย่อในปี 2016 ทำให้แนวทางเดิมมีข้อจำกัด
    • ลิงก์ที่อิงกับ goo.gl ทั้งหมดได้รับผลกระทบ เพราะมีความเสี่ยงในการซ่อนลิงก์อันตราย
  • เนื่องจากไม่ต้องการเก็บข้อมูลผู้ใช้ จึงสร้างเส้นทางของตนเองแบบชั่วคราวในรูป godbolt.org/g/abc123
    • เมื่อเข้าผ่าน godbolt.org/g/abc123 จะรีไดเร็กต์ไปยัง goo.gl/abc123 อีกครั้ง
    • จากนั้นจึงกลับไปยัง URL แบบยาวของ godbolt.org ในท้ายที่สุด
    • การเกิดรีไดเร็กต์หลายต่อทำให้โครงสร้างซับซ้อน
  • ต่อมามีการใช้ Google API เพื่อทำให้ขั้นตอนรีไดเร็กต์บางส่วนง่ายขึ้น

การนำสตอเรจของตนเองมาใช้และการจัดการลิงก์

  • ตั้งแต่ปี 2018 เป็นต้นมา ปัญหา ข้อจำกัดความยาวของ URL และความไม่สะดวกของการบีบอัดข้อมูลเริ่มเป็นประเด็นบ่อยครั้ง
  • จึงได้ สร้างโครงสร้างจัดเก็บของตนเองด้วย S3 และ DynamoDB
    • นำค่าอินพุตไป แฮช แล้วเก็บใน S3 ในรูปแบบ เอกสาร JSON
    • เมื่อเข้าผ่านลิงก์สั้น (godbolt.org/z/hashbit) จะไปค้นหาแมปปิงใน DynamoDB
    • หากค่าแฮชมีคำหยาบหรือคำไม่เหมาะสม จะมีฟังก์ชันตรวจสอบเพื่อหลบเลี่ยงด้วยการเพิ่มองค์ประกอบแบบสุ่ม
    • มีการแก้ปัญหาความไม่เหมาะสมของลิงก์แบบแฮชและเคยพบบั๊กที่เกี่ยวข้อง (เช่น issue #1297)
  • ปัจจุบันยังคงรองรับรูปแบบที่อยู่ godbolt.org/g/abc123 อยู่
  • แม้ Google จะประกาศอย่างเป็นทางการแล้วว่า goo.gl เปลี่ยนเป็นโหมดอ่านอย่างเดียว และจะปิดตัวสมบูรณ์ในเดือนสิงหาคม 2025
  • ลิงก์ย่อที่อิงกับ goo.gl จะไม่สามารถตีความได้อีกต่อไป
  • แต่รูปแบบ godbolt.org/g/abc123 สามารถ ยืดอายุการใช้งานได้ด้วยการดูแลเองโดยตรง จึงมีการดำเนินงานกู้ลิงก์เหล่านี้อย่างเป็นระบบ

การรวบรวมลิงก์เลกาซีจำนวนมากและงานจัดเก็บถาวร

  • ช่วงหลังมีการครอว์ลิงและทำฐานข้อมูลของลิงก์เลกาซีจากทุกแหล่งที่เป็นไปได้ (การค้นหา, data dump, weblog ฯลฯ)
    • Google Web Search API
    • GitHub API
    • เซิร์ฟเวอร์ล็อกของตนเอง
    • Stack Overflow data dump จาก archive.org
    • ข้อมูลหน้าเว็บที่ Archive.org จัดเก็บไว้
  • กู้ลิงก์ย่อกลับคืนมาได้สำเร็จประมาณ 12,298 รายการ
  • ภายในระบบได้เริ่มใช้ฐานข้อมูลลิงก์ของตนเองแทน goo.gl แล้ว (PR ที่เกี่ยวข้อง: #7724)
  • ต่อจากนี้ก็มีแผนจะเก็บรวบรวมและสำรองลิงก์ godbolt.org/g/abc123 ที่ยังไม่ถูกค้นพบต่อไป
  • หากชุมชนยังมีลิงก์ที่ยังไม่ได้ลงทะเบียน สามารถเข้าใช้งานโดยตรงหรือแจ้งผู้ดูแลเพื่อขอเสริมข้อมูลในฐานข้อมูลได้

ปรัชญาของโครงการและความสำคัญของการเป็นเจ้าของโครงสร้างพื้นฐาน

  • กรณีนี้แสดงให้เห็นถึง ความเสี่ยงของการพึ่งพาความต่อเนื่องของบริการภายนอก (เช่น Google) สำหรับโครงสร้างพื้นฐานสำคัญ
  • การจัดการลิงก์ย่อและโครงสร้างแบ็กอัปเป็นเพียงทางแก้ชั่วคราว และหากจะ รับประกัน URL แบบถาวรอย่างแท้จริง ก็จำเป็นต้องดูแลทั้งบริการด้วยตนเอง
  • ในกระบวนการกู้ลิงก์เลกาซีเก่า ๆ ราวกับเป็นโบราณคดีดิจิทัล ก็ได้ตระหนักว่าลิงก์แต่ละรายการคือ ร่องรอยของการแบ่งปันความรู้ คำถาม และการอธิบายแนวคิดของใครบางคน
  • การจัดเก็บและอนุรักษ์นี้ยังเชื่อมโยงโดยตรงกับ การทำหน้าที่เป็นคลังประวัติศาสตร์ของชุมชนโปรแกรมมิง
  • หากคุณพบลิงก์ Compiler Explorer เก่า ๆ การลองกดเข้าไปดูแม้ตอนนี้ก็ถือเป็นการช่วยอนุรักษ์ความรู้บนอินเทอร์เน็ต
  • ครั้งนี้ การพึ่งพา โครงสร้างพื้นฐานที่ควบคุมได้โดยตรงแทนบุคคลที่สาม ทำให้สามารถทำตามคำมั่นเรื่องความคงอยู่ได้จริง

Disclaimer

  • บทความนี้เขียนโดยมนุษย์ และมีการใช้ LLM ในกระบวนการแนะนำลิงก์และตรวจไวยากรณ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-30
ความคิดเห็นใน Hacker News
  • ก่อนปี 2010 ดูเหมือนจะเป็นเรื่องปกติที่เราจะสมมติว่าลิงก์คงอยู่ตลอดไป เลยใช้ฟีเจอร์บุ๊กมาร์กของเบราว์เซอร์อย่างจริงจัง แต่พอเวลาผ่านไปก็ได้เจอกับประสบการณ์ที่บุ๊กมาร์กจำนวนมากแทบใช้งานไม่ได้เพราะลิงก์เสื่อมสภาพ (linkrot) หลังจากนั้นเลยติดนิสัยเซฟหน้าเว็บเป็น PDF และเมื่อ Reader view แพร่หลายขึ้น ก็เปลี่ยนมาเป็นคัดลอกเนื้อหาจาก Reader view แล้วบันทึกเป็นไฟล์ RTF
    • ฉันใช้ส่วนขยาย SingleFile เพื่อเก็บถาวรทุกหน้าที่เข้าเยี่ยมชม ตั้งค่าและติดตั้งค่อนข้างง่าย แต่ต้องระวังว่าใช้พื้นที่เก็บข้อมูลมากพอสมควร ตัวอย่างเช่น ไดเรกทอรีเก็บถาวรหน้าเว็บมีขนาดถึง 1.1TB ลิงก์ GitHub ของ SingleFile
    • ถ้าติดตั้งส่วนขยายเบราว์เซอร์ Web Archive อย่างเป็นทางการ ก็สามารถตั้งค่าให้เก็บถาวรทุกหน้าที่เข้าเยี่ยมชมโดยอัตโนมัติได้
    • วิธีของฉันคือจำข้อมูลสำคัญ หรืออย่างน้อยจำให้ได้ว่าจะไปหาเจอมันจากที่ไหน ตอนนี้ก็ยังมีชีวิตอยู่ดี ดังนั้นวิธีนี้ก็นับว่าได้ผลในแบบของมัน
    • สงสัยว่ามีส่วนขยายเบราว์เซอร์ที่เมื่อเจอลิงก์หมดเวลาแล้วจะพาไปที่ web.archive.org โดยอัตโนมัติหรือไม่
    • มีวิธีใช้ฟอร์แมต WARC ร่วมกับ WebRecorder ข้อมูล WARC, WebRecorder
  • การร่วมมือกับโครงการ Goo.gl ของ ArchiveTeam อาจเป็นเรื่องที่คุ้มค่า รายละเอียดโครงการ การย่อ URL น่าจะเป็นหนึ่งในไอเดียที่แย่ที่สุดจริง ๆ คำอธิบาย URLTeam
    • ตามสถานะแบบเรียลไทม์ของโครงการ พบ goo.gl URL แล้ว 7.5 พันล้านรายการ จากทั้งหมด 42.5 พันล้านรายการ ลิงก์สถานะแบบเรียลไทม์
    • ArchiveTeam น่าจะไม่ได้ใช้ลิงก์ที่ "รู้จักอยู่แล้ว" แต่ใช้วิธี brute force กับ Goo.gl short URL มากกว่า น่าจะมี URL ของ Compiler Explorer ส่วนใหญ่หรืออาจทั้งหมดอยู่ในข้อมูลของพวกเขา ดังนั้นการติดต่อไปน่าจะเป็นความคิดที่ดี
  • การที่ URL จะคงอยู่ตลอดไปเป็นความฝันในอุดมคติ แต่ในความเป็นจริง URL 99% ไม่ได้ถาวรอยู่แล้ว เลยคิดว่าบางทีแทนที่จะสู้กับศึกที่แพ้แน่ต่อไป เราควรสร้างเทคโนโลยีโดยตั้งสมมติฐานว่าโครงสร้างพื้นฐานไม่ได้ถาวรหรือไม่
    • การสร้างเทคโนโลยีโดยตั้งสมมติฐานว่าโครงสร้างพื้นฐานไม่ถาวรน่าจะเป็นทิศทางที่ถูกต้อง และก็ควรหลีกเลี่ยงการใช้บริการย่อ URL ราวกับเป็นโครงสร้างพื้นฐานด้วย
    • URN (Uniform Resource Name) เป็นระบบที่ออกแบบมาเพื่อให้ตัวตนกับทรัพยากรโดยไม่ขึ้นกับตำแหน่ง แต่ไม่เคยแพร่หลายจริง ๆ และในทางกลับกัน บริการย่อ URL ก็เหมือนพยายามทำสิ่งคล้ายกันแบบไม่สำเร็จ คำอธิบาย URN ในวิกิพีเดีย
    • ชื่อโดเมนเปลี่ยนเจ้าของกันบ่อย และแม้แต่ URL ที่ดูเหมือนถาวรก็อาจกลายสภาพเป็นลิงก์ฟิชชิงอันตรายเมื่อเวลาผ่านไปได้
    • URL ระบุตำแหน่งของทรัพยากรบนเครือข่ายเท่านั้น ไม่ได้ระบุตัวทรัพยากรเอง จึงไม่จำเป็นต้องถาวรหรือมีเอกลักษณ์ นั่นจึงเป็นที่มาของชื่อ "Uniform Resource Locator" การรับรู้ปัญหานี้นำไปสู่การคิดค้น Digital Object Identifier ในปี 1997
  • การเอาบริการย่อลิงก์มาใช้ผิดวัตถุประสงค์จนกลายเป็นฐานข้อมูล แล้วภายหลังต้องออกตามหาลิงก์ล้ำค่าพวกนั้นกลับคืนมาจากทั่วทุกมุมอินเทอร์เน็ต มันให้ความรู้สึกกวีดีเหมือนกัน
    • จุดประสงค์ดั้งเดิมของการย่อ URL คือทำให้ URL ที่ยาวสั้นลง ที่จริงปัญหาคือคนที่ใช้โดเมนในทางที่ผิดเพื่อซ่อนสแปม การหลอกลวง และเว็บไซต์ผิดกฎหมายผ่าน short URL มากกว่า
    • ดูเหมือนพวกเขาเองก็แค่ใช้บริการย่อ URL เพื่อบีบอัด URL เฉย ๆ เดิมที URL ของพวกเขาเองต่างหากที่เก็บสถานะของคอมไพเลอร์ไว้ราวกับเป็น "ฐานข้อมูล"
  • https://killedbygoogle.com/, Google Go Links (2010~2021) เป็นบริการย่อ URL ของ Google ที่เปิดให้บริการราว 11 ปี ก่อนยุติลงเมื่อ 4 ปีก่อน และลูกค้า Google Workspace ก็สามารถใช้โดเมนแบบกำหนดเองได้ด้วย
    • การยุติบริการโดยแค่ไม่ให้สร้าง short URL ใหม่อีก ("minting new ones") ไม่น่าใช่ปัญหาร้ายแรงนัก แต่การปิดแม้กระทั่ง URL ที่มีอยู่เดิมนั้นไม่ยุติธรรมกว่ามาก โดยเฉพาะเมื่อ Google เองก็ยังใช้ฟีเจอร์นี้อยู่ภายในกับบางแอป
  • ประโยคที่ว่า "บทความนี้เขียนโดยมนุษย์ แต่ข้อเสนอแนะเรื่องลิงก์และการตรวจไวยากรณ์ทำโดย LLM" เป็นสิ่งที่สะดุดตาเป็นอันดับสอง ให้ความรู้สึกเหมือนกำลังเห็นจุดเริ่มต้นของเทรนด์ใหม่บางอย่าง
    • น่าสนใจดีที่ความเป็นจริงทำให้ผู้คนรู้สึกว่าต้องใส่ข้อความชี้แจงแบบนี้
    • สำหรับฉัน ไม่รู้สึกเลยว่าจำเป็นต้องมีข้อความชี้แจงแบบนั้น ถ้าเนื้อหาพิสูจน์ตัวเองได้ก็เพียงพอแล้ว หากคุณภาพของเนื้อหาต่ำ ไม่ว่าจะสร้างโดย AI หรือมนุษย์ก็เป็นปัญหาแบบเดียวกัน คนที่ต้องการข้อความชี้แจงแบบนี้อาจมองมันเป็นเครื่องมือช่วยตัดสินแทน เพราะตัวเองไม่มั่นใจว่าจะประเมินเนื้อหาได้ และถือว่าเนื้อหาที่สร้างโดย AI มีคุณภาพต่ำโดยปริยาย
  • น่าแปลกใจที่ Google ถึงกับจะปิดแม้กระทั่งเวอร์ชันอ่านอย่างเดียว อดสงสัยไม่ได้ว่าพวกเขากังวลเรื่องความเสี่ยงทางกฎหมายจากการคงระบบ redirect ของลิงก์ส่วนตัวไว้หรือเปล่า
    • ไม่รู้รายละเอียดภายในที่แน่ชัด แต่ก็เป็นไปได้ว่าพวกเขาอยากยุติเพราะบริการนี้พึ่งพาไลบรารีหรือรันไทม์ที่ล้าสมัยหรือมีช่องโหว่ด้านความปลอดภัย ที่จริงแม้ค่าใช้จ่ายจะเล็กน้อย สุดท้ายก็ดูเหมือนเลือกปิดบริการเพื่อลดต้นทุน และให้ความรู้สึกว่าไม่ได้ใส่ใจกับความหวังดีขององค์กรหรือคำมั่นสัญญาในอดีตนัก
  • สงสัยว่าจะมีทางใดบ้างไหมที่จะขอให้พนักงาน Google ดึงเฉพาะ short URL ที่ redirect ไปยัง godbolt.org ออกมาจากฐานข้อมูลให้
  • พูดตรง ๆ เว้นแต่จะมีมูลนิธิที่มีเงินทุนเพียงพอเข้ามาช่วย ทั้ง Compiler Explorer และ godbolt.org ก็คงมีชะตาไม่ถาวรในสักวันหนึ่ง และเป็นไปได้ว่าสุดท้ายข้อมูลทั้งหมดจะถูกทำให้เป็นนามธรรมแล้วบรรจุเข้าไปในโมเดลขนาดมหึมาที่มีพารามิเตอร์จำนวนมหาศาล
    • จนถึงตอนนี้เราบริหารกันมาได้ดี สัปดาห์นี้ครบรอบ 13 ปี และถึงผู้สนับสนุนทั้งหมดจะหยุดสนับสนุน เราก็ยังมีเงินพอให้เดินหน้าต่อได้อีกกว่าหนึ่งปี ช่วงนี้ก็เริ่มคิดเรื่องการตั้งมูลนิธิอยู่เหมือนกัน ที่จริงจุดเปราะบางไม่ใช่เรื่องเงินทุน แต่คือการที่ตัวฉันเองเป็น single point of failure
    • ก็จริง ตอนนี้การที่ลิงก์ Compiler Explorer จะใช้ไม่ได้ก็ต่อเมื่อ Compiler Explorer หายไปจริง ๆ เท่านั้น ก่อนถึงจุดนั้นลิงก์น่าจะยังอยู่ โดยเฉพาะลิงก์ Compiler Explorer ที่แนบในบั๊กรีพอร์ตนั้นมีค่ามาก ฉันเองก็ใส่โค้ดลงไปในรีพอร์ตโดยตรงพร้อมลิงก์แบบนั้น และระบุด้วยว่าใช้คอมไพเลอร์ตัวไหนกับเวอร์ชันอะไร ฉันไม่ได้คิดว่า Compiler Explorer จะหายไปเร็ว ๆ นี้ แต่การทำให้บั๊กรีพอร์ตพึ่งพาตัวเองได้แบบนี้ก็ช่วยรับมือกับการหายไปโดยไม่คาดคิดได้
    • ทำให้นึกถึงมุกตามทฤษฎี no-hiding ที่ว่าข้อมูลจะคงอยู่ตลอดไป
  • การคงโดเมนไว้ก็มีค่าใช้จ่าย เลยไม่รู้ว่า URL จะคงอยู่ตลอดไปได้อย่างไร และก็สงสัยเหมือนกันว่าการเสื่อมสลายของ URL อาจเป็นเรื่องดีเสียด้วยซ้ำหรือไม่ มนุษย์อาจเลือกเก็บรักษาเฉพาะข้อมูลที่มีคุณค่าเป็นพิเศษ และปล่อยให้ส่วนที่เหลือเลือนหายไปตามประวัติศาสตร์
    • แต่นักประวัติศาสตร์กลับต้องการข้อมูล "ขยะ" แบบนั้นให้มากขึ้น เพราะมันช่วยให้เข้าใจชีวิตจริงและบริบทของยุคนั้นได้ดีกว่า ถ้ามีไทม์แมชชีน ฉันก็สงสัยเหมือนกันว่านักประวัติศาสตร์ในอีกพันปีข้างหน้าจะมองยุคนี้อย่างไร ยุคที่ข้อมูลส่วนใหญ่สูญหายไปพร้อมกับการเสื่อมสลายของสื่อดิจิทัล
    • ฉันเองก็เห็นด้วยว่าการที่ URL เสื่อมสลายมีข้อดีอยู่บ้าง และเคยเขียนเรื่องนี้ไว้ ว่าด้วยความไม่ถาวรของอินเทอร์เน็ต