Debian chuyển toàn bộ sang hệ thống thời gian 64 bit mà không chờ tới vấn đề năm 2038

• Debian chính thức áp dụng time_t 64 bit cho cả các kiến trúc 32 bit từ Debian 13 trở đi nhằm chặn trước vấn đề Y2K38 (Unix Epochalypse)
• Do giới hạn của time_t 32 bit hiện tại, sau ngày 19 tháng 1 năm 2038 thời gian có thể bị quay ngược về năm 1900, nên dự án quyết định không tiếp tục để mặc vấn đề này
• Dù phần cứng 64 bit đã an toàn, Debian nhấn mạnh vẫn còn nhu cầu trên các thiết bị 32 bit nhạy cảm về chi phí như embedded, IoT, nên cần xử lý từ sớm
• Một nỗ lực quy mô lớn đang được triển khai để chuyển đồng thời kiểu time_t phân bố trong toàn bộ 6.429 gói, chấp nhận một lần phá vỡ tương thích ABI
• Một số kiến trúc hỗ trợ cũ như i386, hurd-i386 sẽ được giữ làm ngoại lệ, đồng thời cũng đề cập khả năng đưa vào kiến trúc x86 (i686) mới dựa trên time_t 64 bit

---

Debian ứng phó lỗi Y2K38: chuyển sang thời gian 64 bit

• Debian sẽ chuyển sang thời gian 64 bit trong mọi môi trường, ngoại trừ một phần phần cứng lâu đời nhất còn được hỗ trợ, để tránh vấn đề Y2K38 hay Unix Epochalypse sắp tới
• Việc này giúp ngăn lỗi giá trị thời gian sai do vượt phạm vi signed int 32 bit dự kiến xảy ra vào ngày 19 tháng 1 năm 2038

Bối cảnh vấn đề Y2K38 và Unix Epochalypse

• Vấn đề Y2K38 là hiện tượng trong các hệ thống Unix biểu diễn số giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970 bằng signed int 32 bit; khi vượt qua mốc năm 2038 sẽ xảy ra tràn số, khiến thời gian bị quay sai về quá khứ như năm 1900
• Điều này bắt nguồn từ một quyết định kiến trúc chọn kiểu dữ liệu ngắn tương tự như Y2K trước đây (vấn đề năm 2000)
• Khi Y2K xảy ra, các nhà phát triển đã tránh được hỗn loạn lớn nhờ xử lý trước
• Phần mềm cho phần cứng 64 bit vốn đã an toàn, nhưng Debian vẫn được dùng rộng rãi trong các môi trường embedded, cấu hình thấp và legacy

Các biện pháp chính của Debian

• Từ bản phát hành Debian 13 "Trixie", Debian sẽ dùng time_t 64 bit trên mọi kiến trúc chính làm mặc định
• Phần cứng 64 bit đã an toàn, nhưng vấn đề thường xuất hiện trên thiết bị embedded và phần cứng legacy dùng bộ xử lý 32 bit
• Những thiết bị này vẫn đang được dùng trong các lĩnh vực nhạy cảm về chi phí và xuất xưởng số lượng lớn như điều khiển ô tô, IoT, TV và router
• Nhiều thiết bị mới dùng Linux tự build như OpenEmbedded, Alpine, Android, Gentoo, nhưng việc sử dụng thiết bị embedded dựa trên Debian được dự báo vẫn tiếp tục trong vài năm tới

Triển khai và thay đổi

• Biến time_t đang phân tán trong 6.429 gói, nên cần một nỗ lực quy mô lớn
• Thay đổi này có thể phá vỡ tương thích ABI (Application Binary Interface), vì vậy tất cả thư viện và gói liên quan được điều chỉnh đồng thời
• Theo nhóm bảo trì, công việc này đã hoàn tất và được kiểm thử đầy đủ

Ngoại lệ và kế hoạch tương lai

• Cổng i386 (x86 cũ) sẽ tiếp tục dùng time_t 32 bit và được giữ lại nhằm duy trì khả năng chạy các binary hiện có
• Kiến trúc i686 có thể được thảo luận riêng để áp dụng thời gian 64 bit cùng ISA (kiến trúc tập lệnh) mới hơn
• Cổng hurd-i386 sẽ không được chuyển đổi do thiếu hỗ trợ từ kernel; thay vào đó, phương án chuyển sang hurd-amd64 đang được tiến hành

Ghi chú cho nhà phát triển

• Các nhà phát triển có thể kiểm tra xem phần mềm của mình có bị hỏng khi áp dụng biến thời gian 64 bit hay không bằng các hướng dẫn trên wiki Debian
• Thông tin chi tiết và tài liệu kỹ thuật có tại Debian wiki

[GN⁺]

Ý kiến trên Hacker News

• Steve Langasek đã tập trung giải quyết vấn đề này trong những năm cuối đời và thúc đẩy được nhiều tiến triển lớn, từ nay mỗi khi nhìn thấy time_t 64-bit tôi sẽ lại nhớ đến ông ấy
  • Cảm ơn vì đã nhắc lại tin tốt này, tôi nhớ Steve, không biết Joey còn tiếp tục hoạt động với Debian không
• Về vấn đề Y2K (sự cố năm 2000 do biểu diễn năm bằng 2 chữ số), vào thời đó tiết kiệm được 2 byte là rất có giá trị, phần mềm những năm 70~90 thay đổi rất nhanh nên không ai kỳ vọng nó sẽ được dùng quá 5 năm, cách nhìn quá coi thường như vậy có vẻ không công bằng
  • Ngay cả bây giờ biểu diễn năm 2 chữ số vẫn được dùng rất nhiều, ví dụ ngày hết hạn thẻ tín dụng (mm/yy) dùng năm 2 chữ số vì ngắn gọn và tiện viết, đủ cho vòng đời của thẻ nhưng đến năm 2100 có thể lại phát sinh vấn đề chuyển đổi, phần lớn Y2K bắt nguồn từ vấn đề UI (ô nhập văn bản 2 ký tự, hardcode +1900, v.v.), lỗi Y2K tôi từng trực tiếp gặp là một diễn đàn Internet nhảy từ 1999 sang 19100 (chỉ là lỗi hiển thị đơn giản), Y2K không phải chỉ là vấn đề của COBOL
  • Trong những trường hợp như thế này, “tối ưu hóa quá sớm” ngược lại có lẽ còn hữu ích hơn, nếu chỉ biểu diễn ngày bằng một giá trị int đơn giản tính từ năm 1900 là 0 thì còn tiết kiệm được nhiều byte hơn nữa, với 3 byte có thể bao phủ từ năm 1900 đến khoảng 44.000 ngày sau, với 2 byte cũng đủ tới khoảng năm 2070
  • Điều mọi người hay nhầm lẫn là không phải thêm 2 byte mà là phải thêm 2 ký tự, trong COBOL cả số lẫn dữ liệu đều được cấp phát theo độ rộng cố định bằng số ký tự, nên để chen được năm 4 chữ số thì phải có chỗ cho 4 ký tự, kích thước kiểu trường như vậy bị hardcode trên toàn bộ chương trình như truy cập dữ liệu, UI, file batch, file trung gian, file truyền đi, v.v.
  • Tôi có vài người quen từng mua rất nhiều quyền chọn bán vì kỳ vọng cổ phiếu các ngân hàng lớn sẽ lao dốc ngay trước Y2K, nhưng thực tế thì hầu như chẳng có chuyện gì lớn xảy ra
  • Cuối những năm 80 tôi từng làm với COBOL và gặp một chương trình chỉ lưu năm bằng 1 chữ số, lúc nghe giải thích cấu trúc thì thấy rất kỳ lạ, nhưng vì bản ghi tự động bị xóa sau mỗi 4 năm nên trong sử dụng không có vấn đề gì, lúc nào cũng rõ đó là năm nào
• time_t 64-bit sẽ giải quyết Epochalypse, nhưng không phải mọi hệ thống đều chỉ đơn giản chuyển sang số giây 64-bit, ext4 đã đổi sang độ phân giải phần thập phân 30-bit (mức nano giây) và độ phân giải giây 34-bit, nhưng vài trăm năm nữa vấn đề vẫn sẽ quay lại, tôi đoán rồi một lúc nào đó mọi thứ sẽ ổn định ở dấu thời gian 128-bit gồm 64-bit giây + 64-bit phần lẻ, như vậy sẽ bao phủ toàn bộ tương lai có thể dự đoán trong lịch sử loài người
  • Thời gian tính bằng giây 64-bit tương đương khoảng 585 tỷ năm, kết quả tính trên WolframAlpha
  • Ngay cả độ phân giải phần lẻ 64-bit có lẽ cũng chưa đủ, nếu muốn tiến gần đến thời gian Planck thì phải dùng tới 144 bit
  • Tôi vốn đã tò mò về timestamp của ext4, giờ lại thấy muốn tìm hiểu thêm zfs và btrfs xử lý thời gian thế nào, btrfs chắc có lẽ dùng 64-bit, còn zfs cũng vậy (hay có thể tôi đang nhầm với ext4)
• Bài viết nói Debian đang giải quyết Y2K38, tức vấn đề Unix Epochalypse, nhưng thực ra họ đã hoàn tất chuyển sang time64_t trên mọi port 32-bit trừ i386, i386 là ngoại lệ duy nhất vì tương thích nhị phân cũ, còn lại tất cả kể cả m68k đều đã đổi, tôi đã tự mình chuyển đổi m68k, powerpc, sh4 và hppa
• time_t không phải biến (variable) mà là kiểu dữ liệu
  • Nội dung trong bài dựa trên wiki Debian, bản gốc ghi rõ rằng “time_t thực sự xuất hiện khắp nơi. Trong 35.960 gói, nó xuất hiện trong mã nguồn của 6.429 gói. Những gói để lộ ABI của struct chứa time_t thì phải di trú toàn bộ ABI cùng lúc”, wiki giải thích rõ hơn bài báo khá nhiều
  • “For everything” được ghi rõ là áp dụng cho armel, armhf, hppa, m68k, powerpc, sh4 chứ không phải i386, i386 không còn tương lai và mục đích chính là chạy nhị phân/thư viện động cũ nên không muốn làm nó bị vỡ
  • “Dự kiến áp dụng sau khi Debian 13 Trixie phát hành” thực ra có nghĩa là nó sẽ được bao gồm trong Trixie
• Tôi cũng mong giới hạn độ dài dòng lệnh được chuyển thành không giới hạn hoặc động, có tới 96GB RAM mà vẫn hay bị lỗi “argument list too long” rất phiền
  • Có thể biên dịch lại kernel để gỡ giới hạn độ dài dòng lệnh (khoảng 100 nghìn ký tự), tham khảo trên stackoverflow, nhưng không giống một cách giải quyết tận gốc, cũng chẳng rõ sẽ dùng đối số dài như một ảnh JPEG 4k vào việc gì
  • Chỉ cần tăng giá trị RLIMIT_STACK, ví dụ ulimit -s 4000 là stack 4MB, muốn lớn hơn thì sửa /etc/security/limits.conf rồi đăng nhập lại
  • Có lẽ cứ đóng gói bằng Electron rồi gửi qua yêu cầu JSON bằng HTTP POST là được chăng
  • Chỉ cần định nghĩa lại MAX_ARG_STRLEN rồi biên dịch lại kernel, hoặc dùng máy có kích thước trang lớn hơn (ví dụ kernel RHEL Arm với page size 64k), nhưng dùng pipe thay cho command buffer để truyền dữ liệu giữa các tiến trình thì dễ hơn nhiều
  • Giới hạn đường dẫn file cũng là vấn đề tương tự, một số build system (Debian + python + dh-virtualenv, v.v.) có thể khiến đường dẫn rất dài, cứ cho phép luôn thì tiện hơn
• Dù đổi sang 64-bit thì một lúc nào đó giới hạn vẫn sẽ tới, tôi tò mò không biết loài người sẽ làm gì vào lúc 15:30:07 UTC ngày 4 tháng 12 năm 292277026596
  • Có lẽ tới lúc đó họ sẽ kỷ niệm 100 năm ngày IPv6 được triển khai hoàn toàn
  • Trong vòng 5 tỷ năm nữa Mặt Trời sẽ trở thành sao khổng lồ đỏ và toàn bộ bề mặt Trái Đất sẽ bốc hơi
  • Đến lúc đó hy vọng chúng ta đã chuyển sang một hệ lịch tốt hơn, dù tất nhiên vấn đề timestamp vẫn còn đó
  • Chỉ cần chuyển sang thời gian 128-bit là được
  • Có vẻ có thể áp dụng RFC 2550 (Y10K & beyond), được công bố ngày 1 tháng 4 năm 1999
• Đã 11 năm kể từ khi OpenBSD 5.5 áp dụng thay đổi tương tự, ghi chú phát hành OpenBSD 5.5
  • Đây là trường hợp đã vượt lên trước tất cả, tôi từng phát hiện API 32-bit của OS/2 trong thập niên 90 trả về thời gian 64-bit và đã tự viết thư viện chuẩn C++ với time_t 64-bit để dùng
  • Dù là câu chuyện hơi khác, nhưng đúng lúc như thế này lại nảy ra ý muốn chuyển máy chủ sang OpenBSD thay vì Linux
  • OpenBSD ít phải bận tâm về tương thích hơn, lại có số người dùng ít hơn nhiều nên khi thay đổi thì xác suất gặp bug hoặc edge case cũng thấp hơn
• Khi nói “Debian giờ đã đủ hoàn thiện và được kiểm thử nên sẽ chuyển đổi sau khi Trixie phát hành”, tôi thắc mắc liệu điều đó có nghĩa là Trixie sẽ không có thay đổi này không
  • Trong ghi chú phát hành Trixie có nói là sẽ được áp dụng, ghi chú phát hành Trixie
• Đây là lần đầu tôi nghe Y2K38 được gọi là Unix Epochalypse, nghe dễ thương nên có khi sẽ lan rộng thật
  • Wikipedia về Year 2038 Problem cũng có tên gọi đó, nó được dùng như một cách nói đùa từ năm 2017 rồi lan ra
  • Cũng có dự án epochalypse-project.org
  • Cụm “it’s kind of fetch” có vẻ là một câu đùa nhắc đến phim Mean Girls
  • Còn khoảng 12 năm 5 tháng 22 ngày 13 giờ 22 phút nữa là đến Epochalypse