การเปิดตัว Glibc 2.36 ได้สร้างความวุ่นวายอย่างมากในชุมชนเกมมิ่ง Linux ทำให้เกมจำนวนมากเล่นไม่ได้และจุดประกายการถกเถียงเรื่องความเสถียรของ application binary interface (ABI) บนแพลตฟอร์มนี้อีกครั้ง ปัญหานี้เกิดจากการเปลี่ยนแปลงในวิธีที่ GNU C Library จัดการ symbol hash tables ส่งผลกระทบต่อเกมที่ใช้ Easy Anti-Cheat (EAC) และ Epic Online Services (EOS) รวมถึงซอฟต์แวร์อื่นๆ
สาเหตุทางเทคนิคที่แท้จริง
ปัญหาเกิดจากวิธีการสองแบบในการจัดหา symbol hash tables ในรูปแบบ ELF คือ DT_HASH และ DT_GNU_HASH แม้ว่า DT_HASH จะเป็นส่วนหนึ่งของมาตรฐาน SYSV generic ABI และมีเอกสารครบถ้วน แต่ DT_GNU_HASH เป็นตัวทดแทนที่ใหม่กว่าและเร็วกว่า แต่ขาดเอกสารที่เหมาะสม เป็นเวลาหลายปีที่ Glibc รักษาความเข้ากันได้โดยรวม hash table formats ทั้งสองแบบ แต่เวอร์ชัน 2.36 ได้ยกเลิกข้อกำหนดนี้ โดยอาศัยการตั้งค่าเริ่มต้นที่อาจรวมเฉพาะตัวแปร GNU เท่านั้น
การเปลี่ยนแปลงนี้ทำให้เกมชื่อดังหลายเกมเสียหาย รวมถึงเกมที่ใช้การป้องกัน EAC EOS เกมอินดี้อย่าง Shovel Knight และโปรเจกต์โอเพนซอร์สอย่าง frame rate limiter libstrangle คาดว่าผลกระทบจะเพิ่มมากขึ้นเมื่อดิสทริบิวชันหลักๆ เริ่มใช้ Glibc 2.36
หมายเหตุ: ELF (Executable and Linkable Format) เป็นรูปแบบไฟล์มาตรฐานสำหรับไฟล์ปฏิบัติการและไลบรารีบนระบบ Linux
การเปรียบเทียบ Hash Table
- DT_HASH: เป็นส่วนหนึ่งของ SYSV generic ABI มีเอกสารครบถ้วน เป็นมาตรฐานบังคับ
- DT_GNU_HASH: ตัวทดแทนที่ใหม่กว่า มีขนาดเล็กกว่าและเร็วกว่า แต่มีเอกสารไม่ครบถ้วน
- การประหยัดพื้นที่: การลบ DT_HASH ช่วยประหยัดพื้นที่ประมาณ 16KB ต่อไฟล์ binary (น้อยกว่า 1% ของขนาดรวม)
- ความเข้ากันได้: GNU linker ใช้ค่าเริ่มต้นเป็น "both" ขณะที่ mold linker ใช้ค่าเริ่มต้นเป็น "sysv"
การตอบสนองของชุมชนและวิธีแก้ไขชั่วคราว
ชุมชนเกมมิ่ง Linux ตอบสนองด้วยปฏิกิริยาที่หลากหลายต่อการพัฒนานี้ นักพัฒนาบางคนโต้แย้งว่าควรเปลี่ยนโฟกัสไปที่การทำให้เกมทำงานได้อย่างสมบูรณ์แบบผ่าน Proton (เลเยอร์ความเข้ากันได้ของ Windows ของ Valve) แทนที่จะรักษาเวอร์ชัน Linux แบบเนทีฟ ความรู้สึกนี้สะท้อนถึงความหงุดหงิดที่เพิ่มขึ้นต่อความท้าทายในการพัฒนาเกม Linux แบบเนทีฟ
นักพัฒนาเกมควรโฟกัส 100% ในการทำให้เกมของพวกเขาทำงานได้อย่างสมบูรณ์แบบบน Proton แทนที่จะปล่อยเวอร์ชัน Linux ที่ทำได้แค่ครึ่งๆ กลางๆ
คนอื่นๆ สนับสนุนแนวทางการพัฒนาข้ามแพลตฟอร์มที่ดีกว่าตั้งแต่เริ่มต้น โดยแนะนำว่านักพัฒนาควรหลีกเลี่ยงเทคโนโลยีเฉพาะแพลตฟอร์มอย่าง DirectX และใช้ทางเลือกข้ามแพลตฟอร์มอย่าง Vulkan แทน อย่างไรก็ตาม ความจริงคือเกมที่มีอยู่หลายเกมไม่สามารถแก้ไขหรือคอมไพล์ใหม่เพื่อรองรับการเปลี่ยนแปลงเหล่านี้ได้อย่างง่ายดาย
ซอฟต์แวร์ที่ได้รับผลกระทบ
- เกมที่ใช้ Easy Anti-Cheat (EAC) และ Epic Online Services (EOS)
- Shovel Knight (เกมอินดี้)
- libstrangle (ตัวจำกัดเฟรมเรตแบบโอเพนซอร์ส)
- คาดว่าจะมีซอฟต์แวร์เพิ่มเติมที่ได้รับผลกระทบเมื่อ Glibc 2.36 เข้าสู่การแจกจ่ายหลัก
ผลกระทบในวงกว้าง
เหตุการณ์นี้เน้นย้ำถึงความตึงเครียดพื้นฐานในการพัฒนา Linux ระหว่างความก้าวหน้าทางเทคนิคและความเข้ากันได้แบบย้อนหลัง แม้ว่าการเปลี่ยนแปลงนี้จะประหยัดพื้นที่ได้ทางเทคนิค (ประมาณ 16KB ต่อไบนารี) และไม่ถือว่าเป็นการทำลาย ABI อย่างเป็นทางการ แต่ก็มีผลกระทบในโลกแห่งความจริงต่อผู้ใช้และนักพัฒนา สถานการณ์นี้ซับซ้อนขึ้นเพราะดิสทริบิวชันต่างๆ อาจจัดการกับการเปลี่ยนแปลงนี้แตกต่างกัน ซึ่งอาจเพิ่มการแยกส่วน
ความขัดแย้งนี้ยังเน้นย้ำถึงเหตุผลที่นักพัฒนาบางคนพบว่าการพัฒนา Windows คาดเดาได้มากกว่า แม้จะมีข้อได้เปรียบทางเทคนิคของ Linux ที่น่าสนใจคือสมาชิกชุมชนหลายคนสังเกตว่า Proton บางครั้งให้ประสิทธิภาพเกมที่ดีกว่า Windows แบบเนทีฟ โดยยกตัวอย่างเช่น Elden Ring ที่การแก้ไข DirectX 12 translation ถูกนำไปใช้ใน Wine's VKD3D เร็วกว่าใน Windows เอง
บทสรุป
สถานการณ์ Glibc 2.36 เป็นเครื่องเตือนใจถึงความท้าทายที่ต่อเนื่องที่ Linux เผชิญในฐานะแพลตฟอร์มเกมมิ่ง แม้ว่าคุณค่าทางเทคนิคของการเปลี่ยนแปลงจะเป็นที่ถกเถียงได้ แต่ผลกระทบต่อซอฟต์แวร์ที่มีอยู่แสดงให้เห็นถึงความสมดุลที่ละเอียดอ่อนระหว่างนวัตกรรมและความเสถียรในระบบนิเวศโอเพนซอร์ส ในขณะที่ภูมิทัศน์เกมมิ่ง Linux ยังคงพัฒนาต่อไป เหตุการณ์นี้อาจเร่งแนวโน้มไปสู่เลเยอร์ความเข้ากันได้อย่าง Proton แทนที่จะเป็นการพัฒนาแบบเนทีฟ ซึ่งเปลี่ยนแปลงวิธีที่เกมเข้าถึงผู้ใช้ Linux อย่างพื้นฐาน