Debian เปลี่ยนสู่ระบบเวลา 64 บิตเต็มรูปแบบโดยไม่รอปัญหาปี 2038

• เพื่อ ป้องกันปัญหา Y2K38 (Unix Epochalypse) ล่วงหน้า Debian ได้ประกาศอย่างเป็นทางการว่า ตั้งแต่ Debian 13 เป็นต้นไป จะใช้ time_t แบบ 64 บิตแม้กับสถาปัตยกรรม 32 บิต
• จาก ข้อจำกัดของ time_t แบบ 32 บิตเดิม ที่อาจทำให้หลังวันที่ 19 มกราคม 2038 เวลาเด้งย้อนกลับไปเป็นปี 1900 ได้ จึงตัดสินใจว่าจะไม่ปล่อยปัญหานี้ค้างไว้อีกต่อไป
• แม้ฮาร์ดแวร์ 64 บิตจะปลอดภัยอยู่แล้ว แต่ก็ยังมี ความต้องการใช้ Debian ในอุปกรณ์ 32 บิตที่อ่อนไหวต่อด้านต้นทุน เช่น embedded และ IoT จึงจำเป็นต้องรับมือไว้ล่วงหน้า
• กำลังมีงานขนาดใหญ่เพื่อ เปลี่ยนชนิด time_t ที่กระจายอยู่ในแพ็กเกจทั้งหมด 6,429 แพ็กเกจพร้อมกัน โดยยอมรับการแตกหักของความเข้ากันได้ระดับ ABI
• สถาปัตยกรรมรุ่นเก่าบางส่วน เช่น i386 และ hurd-i386 จะยังคงเป็นข้อยกเว้น แต่ก็มีการกล่าวถึงความเป็นไปได้ในการเพิ่มสถาปัตยกรรม x86 (i686) ที่ใช้ time_t แบบ 64 บิต

---

การรับมือบั๊ก Y2K38 ของ Debian: เปลี่ยนไปใช้เวลา 64 บิต

• Debian กำลังเปลี่ยนไปใช้ระบบเวลา 64 บิตในทุกสภาพแวดล้อม ยกเว้นฮาร์ดแวร์รุ่นเก่าที่สุดบางส่วนที่ยังรองรับอยู่ เพื่อหลีกเลี่ยงปัญหา Y2K38 หรือ Unix Epochalypse ที่กำลังจะมาถึง
• แนวทางนี้ช่วยป้องกัน ความผิดพลาดของค่าเวลาอันเกิดจากการเกินขอบเขตของ signed int 32 บิต ซึ่งมีกำหนดจะเกิดในวันที่ 19 มกราคม 2038

เบื้องหลังปัญหา Y2K38 และ Unix Epochalypse

• ปัญหา Y2K38 คือปรากฏการณ์ในระบบ Unix ที่เก็บ จำนวนวินาทีที่ผ่านไปนับจากวันที่ 1 มกราคม 1970 ด้วย signed int 32 บิต ซึ่งเมื่อเลยปี 2038 ไปแล้วจะเกิด overflow ทำให้เวลาเด้งย้อนกลับไปเป็นอดีต เช่น ปี 1900
• นี่มีที่มาจาก การตัดสินใจเชิงสถาปัตยกรรมที่เลือกใช้ชนิดข้อมูลแบบสั้น คล้ายกับกรณี Y2K ในอดีต
• ตอนเกิด Y2K สามารถหลีกเลี่ยงความโกลาหลครั้งใหญ่ได้ด้วยการรับมือล่วงหน้าของนักพัฒนา
• แม้ ซอฟต์แวร์สำหรับฮาร์ดแวร์ 64 บิตจะปลอดภัยอยู่แล้ว แต่ Debian ก็ยังถูกใช้อย่างกว้างขวางในสภาพแวดล้อมแบบ embedded, เครื่องสเปกต่ำ และระบบเก่า

การรับมือหลักของ Debian

• ตั้งแต่การออก Debian 13 "Trixie" เป็นต้นไป จะตั้งค่า time_t แบบ 64 บิตเป็นค่าปริยายในทุกสถาปัตยกรรมหลัก
• ฮาร์ดแวร์ 64 บิตนั้นปลอดภัยอยู่แล้ว แต่ปัญหานี้มักพบใน อุปกรณ์ embedded และฮาร์ดแวร์รุ่นเก่าที่ใช้โปรเซสเซอร์ 32 บิต
• อุปกรณ์เหล่านี้ยังถูกใช้อยู่ใน งานที่อ่อนไหวด้านต้นทุนและมีการผลิตจำนวนมาก เช่น ระบบควบคุมรถยนต์, IoT, ทีวี และเราเตอร์
• แม้อุปกรณ์รุ่นใหม่จำนวนมากจะใช้ลินุกซ์แบบคอมไพล์เอง เช่น OpenEmbedded, Alpine, Android และ Gentoo แต่ การใช้งานอุปกรณ์ embedded ที่อิง Debian ก็คาดว่าจะยังมีต่อไปอีกหลายปี

การนำไปใช้และการเปลี่ยนแปลง

• ตัวแปร time_t กระจายอยู่ในโค้ดที่ครอบคลุม 6,429 แพ็กเกจ จึงต้องใช้ความพยายามขนาดใหญ่
• การเปลี่ยนแปลงครั้งนี้อาจทำให้ ความเข้ากันได้ของ ABI (Application Binary Interface) แตกหัก จึงต้องปรับพร้อมกันในไลบรารีและแพ็กเกจที่เกี่ยวข้องทั้งหมด
• ตามข้อมูลจากทีมดูแล งานนี้เสร็จสิ้นแล้วและผ่านการทดสอบอย่างเพียงพอ

ข้อยกเว้นและแผนในอนาคต

• พอร์ต i386 (x86 เดิม) จะยังคงใช้ time_t แบบ 32 บิตต่อไป โดยคงไว้เพื่อ ความเข้ากันได้ในการรันไบนารีเดิม
• อาจมีการหารือแยกต่างหากเกี่ยวกับ สถาปัตยกรรม i686 ที่ใช้เวลา 64 บิตและ ISA (สถาปัตยกรรมชุดคำสั่ง) แบบใหม่
• พอร์ต hurd-i386 จะไม่ถูกเปลี่ยน เนื่องจากการรองรับจากเคอร์เนลยังไม่เพียงพอ และกำลังมีการผลักดันแนวทางย้ายไปยัง hurd-amd64 แทน

หมายเหตุสำหรับนักพัฒนา

• นักพัฒนาสามารถทดสอบได้ผ่านวิธีที่แนะนำใน Debian wiki ว่า ซอฟต์แวร์ของตนจะ ไม่พังเมื่อมีการใช้ตัวแปรเวลาแบบ 64 บิต
• รายละเอียดเพิ่มเติมและเอกสารทางเทคนิคดูได้ที่ Debian wiki

[GN⁺]

ความเห็นจาก Hacker News

• Steve Langasek ทุ่มเทช่วงหลายปีสุดท้ายของชีวิตไปกับการแก้ปัญหานี้ และผลักดันความคืบหน้าครั้งใหญ่ ต่อไปทุกครั้งที่เห็น 64-bit time_t ก็จะนึกถึงเขา
  • ขอบคุณที่นำข่าวดีนี้มาบอกอีกครั้ง คิดถึง Steve และสงสัยว่า Joey ยังทำงานกับ Debian อยู่หรือไม่
• สำหรับปัญหา Y2K (ปัญหาปี 2000 ที่เกิดจากการแทนปีด้วย 2 หลัก) ตอนนั้นการประหยัด 2 ไบต์มีคุณค่ามากจริง ๆ และซอฟต์แวร์ยุค 70~90 เปลี่ยนเร็วมากจนไม่มีใครคาดว่าจะถูกใช้นานเกิน 5 ปี มุมมองที่ชอบลดทอนเรื่องนี้ดูไม่ค่อยยุติธรรม
  • ตอนนี้ก็ยังมีการใช้ปี 2 หลักกันมากอยู่ เช่น วันหมดอายุบัตรเครดิต (mm/yy) เพราะเขียนสั้นและสะดวก จึงใช้การแทนปีแบบ 2 หลัก ซึ่งเพียงพอกับอายุการใช้งานของบัตร แต่พอถึงปี 2100 ก็อาจเกิดปัญหาในการแปลงค่าได้ ปัญหา Y2K ส่วนใหญ่เกิดจาก UI (ช่องข้อความ 2 ตัวอักษร, hardcode +1900 ฯลฯ) บั๊ก Y2K ที่เคยเจอเองคือเว็บบอร์ดอินเทอร์เน็ตแสดงปีจาก 1999 เป็น 19100 (เป็นแค่ข้อผิดพลาดด้านการแสดงผล) และ Y2K ไม่ได้เป็นปัญหาของ COBOL อย่างเดียว
  • ในกรณีแบบนี้ “การปรับให้เหมาะสมเร็วเกินไป” กลับน่าจะช่วยได้ ถ้าแทนวันที่ด้วยค่า int ธรรมดาที่มีค่าเป็น 0 ในปี 1900 ก็จะประหยัดไบต์ได้มากกว่าอีก ใช้ 3 ไบต์เก็บได้ตั้งแต่ปี 1900 ถึงประมาณ 44,000 และใช้แค่ 2 ไบต์ก็ครอบคลุมได้ถึงราวปี 2070
  • จุดที่คนมักสับสนคือ ไม่ใช่แค่ต้องเพิ่ม 2 ไบต์ แต่ต้องเพิ่ม 2 ตัวอักษรด้วย ใน COBOL ไม่ว่าจะเป็นตัวเลขหรือข้อมูลก็ถูกจัดสรรเป็นความกว้างคงที่ตามขนาดตัวอักษร ดังนั้นถ้าจะใส่ปี 4 หลักก็ต้องมีพื้นที่ 4 ตำแหน่ง ขนาดฟิลด์แบบนี้ถูก hardcode ไว้ทั่วทั้งโปรแกรม ทั้งการเข้าถึงข้อมูล, UI, batch file, ไฟล์กลาง, ไฟล์ส่งต่อ ฯลฯ
  • ก่อน Y2K ไม่นาน มีคนรู้จักที่คาดหวังว่าหุ้นธนาคารใหญ่จะร่วงหนักเลยซื้อ put option จำนวนมาก แต่สุดท้ายแทบไม่มีอะไรใหญ่โตเกิดขึ้น
  • ตอนทำงานกับ COBOL ช่วงปลายยุค 80 เคยเจอโปรแกรมที่เก็บปีแค่ 1 หลัก ตอนฟังอธิบายโครงสร้างก็คิดว่าแปลก แต่เนื่องจากข้อมูลจะถูกลบอัตโนมัติทุก 4 ปี จึงไม่มีปัญหาในการใช้งาน และชัดเจนเสมอว่าหมายถึงปีไหน
• 64-bit time_t จะแก้ปัญหา Epochalypse ได้ แต่ไม่ใช่ว่าทุกระบบจะไปใช้แค่จำนวนวินาทีแบบ 64 บิตตรง ๆ เช่น ext4 เปลี่ยนไปใช้ความละเอียดเศษส่วน 30 บิต (ระดับนาโนวินาที) และความละเอียดวินาที 34 บิตแล้ว แต่สุดท้ายอีกหลายร้อยปีก็จะเจอปัญหาอีกอยู่ดี คาดว่าสุดท้ายสักวันจะลงเอยที่ timestamp 128 บิตแบบ 64-bit วินาที + 64-bit เศษส่วน ซึ่งจะครอบคลุมอนาคตที่มนุษย์คาดการณ์ได้ทั้งหมด
  • เวลาแบบ 64-bit วินาทีเทียบได้ราว 5.85 แสนล้านปี, ผลคำนวณจาก WolframAlpha
  • แม้แต่ความละเอียดเศษส่วน 64 บิตก็อาจยังไม่พอ ถ้าจะเข้าใกล้ Planck time ต้องใช้ถึง 144 บิต
  • เดิมก็สงสัยเรื่อง timestamp ของ ext4 อยู่แล้ว เลยอยากรู้ต่อว่าไฟล์ซิสเต็ม zfs กับ btrfs จัดการเวลาอย่างไร btrfs น่าจะใช้ 64 บิต และ zfs ก็น่าจะคล้ายกัน (อาจจำสลับกับ ext4)
• มีคนบอกว่า Debian กำลังแก้ Y2K38 หรือปัญหา Unix Epochalypse แต่จริง ๆ แล้วได้ย้าย 32-bit port ทั้งหมดไปเป็น time64_t แล้ว ยกเว้น i386 เท่านั้น ข้อยกเว้นนี้เกิดจากความเข้ากันได้กับไบนารีเดิม ส่วนที่เหลือรวมถึง m68k ก็เปลี่ยนหมดแล้ว โดยผู้แสดงความเห็นคนนี้เป็นคนทำ migration ให้ m68k, powerpc, sh4 และ hppa เอง
• time_t ไม่ใช่ตัวแปร แต่เป็นชนิดข้อมูล
  • เนื้อหาในบทความอิงจาก Debian wiki โดยต้นฉบับระบุชัดว่า “time_t ปรากฏอยู่ทั่วไปจริง ๆ พบในซอร์สโค้ดของ 6,429 แพ็กเกจจากทั้งหมด 35,960 แพ็กเกจ แพ็กเกจที่เปิดเผย struct ที่มี time_t อยู่ใน ABI จำเป็นต้องย้าย ABI ทั้งหมดพร้อมกัน” ซึ่ง wiki อธิบายได้ชัดกว่าบทความ
  • คำว่า “For everything” หมายถึง armel, armhf, hppa, m68k, powerpc, sh4 ไม่รวม i386 โดยระบุชัดว่า i386 ไม่มีอนาคตแล้ว และมีไว้หลัก ๆ เพื่อรันไบนารี/ไลบรารีไดนามิกเดิม จึงไม่อยากให้มันพัง
  • ข้อความว่า “จะนำไปใช้หลัง Debian 13 Trixie ออก” ในความเป็นจริงหมายถึงมันรวมอยู่ใน Trixie
• อยากให้มีการเปลี่ยนข้อจำกัดความยาวบรรทัดคำสั่งให้เป็นไม่จำกัดหรือปรับแบบไดนามิกได้ด้วย มีแรม 96GB แต่ก็ยังเจอ error “argument list too long” บ่อยจนรำคาญ
  • สามารถ recompile kernel เพื่อปลดข้อจำกัดความยาวบรรทัดคำสั่ง (ราว 100,000 ตัวอักษร) ได้, ดูใน stackoverflow แต่ก็ดูไม่ใช่การแก้ปัญหาที่ต้นเหตุ และก็สงสัยว่าจะเอาอาร์กิวเมนต์ยาวระดับไฟล์ JPEG 4k ไปใช้ทำอะไร
  • แค่เพิ่มค่า RLIMIT_STACK ก็พอ เช่น ulimit -s 4000 คือ stack 4MB ถ้าจะให้มากกว่านี้ต้องแก้ /etc/security/limits.conf แล้วล็อกอินใหม่
  • หรือจะห่อใส่ Electron แล้วส่งต่อด้วยคำขอ http post json ก็ได้มั้ง
  • recompile kernel โดยนิยาม MAX_ARG_STRLEN ใหม่ก็ได้ หรือใช้เครื่องที่มี page size ใหญ่กว่า (เช่น RHEL Arm kernel ที่ใช้ page size 64k) แต่การใช้ pipe ส่งข้อมูลระหว่างโปรเซสแทน command buffer ง่ายกว่ามาก
  • ข้อจำกัดความยาว path ก็เป็นปัญหาแบบเดียวกัน บาง build system (Debian + python + dh-virtualenv ฯลฯ) ทำให้ path ยาวมากได้ ซึ่งถ้าปล่อยให้ผ่านไปเลยก็น่าจะสะดวกกว่า
• ต่อให้เปลี่ยนเป็น 64 บิต สุดท้ายวันหนึ่งก็จะชนขีดจำกัดอยู่ดี เลยสงสัยว่ามนุษยชาติจะทำอะไรกันในวันที่ 4 ธันวาคม ปี 292277026596 เวลา 15:30:07 (UTC)
  • ตอนนั้นอาจกำลังฉลองครบ 100 ปีของการใช้งาน ipv6 แบบสมบูรณ์ก็ได้
  • ภายใน 5 พันล้านปี ดวงอาทิตย์จะกลายเป็น red giant และทำให้พื้นผิวโลกทั้งหมดระเหยไปแล้ว
  • หวังว่าถึงตอนนั้นเราคงย้ายไปใช้ระบบปฏิทินที่ดีกว่านี้แล้ว แน่นอนว่าปัญหา timestamp ก็คงยังอยู่
  • ไปใช้เวลาแบบ 128 บิตก็จบ
  • อาจใช้ RFC 2550 (Y10K & beyond) ได้ ประกาศเมื่อ 1 เมษายน 1999
• ผ่านมาแล้วตั้ง 11 ปีนับตั้งแต่ OpenBSD 5.5 ใช้การเปลี่ยนแปลงแบบเดียวกัน, บันทึกประจำรุ่น OpenBSD 5.5
  • เหมือนชนะทุกคนไปก่อนแล้ว ช่วงยุค 90 เคยพบว่า API แบบ 32 บิตของ OS/2 คืนค่าเวลาเป็น 64 บิต เลยเขียน C++ standard library ที่ใช้ time_t แบบ 64 บิตเองแล้วใช้งานมัน
  • แม้จะเป็นอีกประเด็นหนึ่ง แต่ช่วงแบบนี้ก็ทำให้อยากย้ายเซิร์ฟเวอร์ไปใช้ OpenBSD แทน Linux เหมือนกัน
  • OpenBSD กังวลเรื่องความเข้ากันได้น้อยกว่า และมีผู้ใช้น้อยกว่ามาก ดังนั้นเวลาเปลี่ยนอะไรโอกาสเจอบั๊กหรือ edge case ก็น้อยลง
• ถ้าบอกว่า “ตอนนี้ Debian เสร็จสมบูรณ์และทดสอบเพียงพอแล้ว จึงจะสลับหลัง Trixie ออก” ฟังดูเหมือนจะไม่ถูกนำไปใช้ใน Trixie หรือเปล่า
  • ใน release note ของ Trixie ระบุว่าใช้แล้ว, release note ของ Trixie
• เพิ่งเคยได้ยินการเรียก Y2K38 ว่า Unix Epochalypse ฟังดูน่ารักดี เลยอาจจะแพร่หลายก็ได้
  • ชื่อนี้มีอยู่ใน Wikipedia เรื่อง Year 2038 Problem ด้วย เริ่มใช้กันแบบขำ ๆ ตั้งแต่ปี 2017 แล้วแพร่ต่อมา
  • มีโปรเจกต์ epochalypse-project.org ด้วย
  • วลี “it’s kind of fetch” ดูเหมือนจะเล่นมุกจากหนัง Mean Girls
  • เหลือเวลาอีกประมาณ 12 ปี 5 เดือน 22 วัน 13 ชั่วโมง 22 นาทีจนถึง Epochalypse