Debian ने 2038 समस्या का इंतज़ार किए बिना पूरी तरह 64-बिट समय प्रणाली पर स्विच किया

• Debian ने Y2K38 (Unix Epochalypse) समस्या को पहले से रोकने के लिए अगले संस्करण Debian 13 से 32-बिट आर्किटेक्चर तक 64-बिट time_t लागू करने को आधिकारिक रूप दिया है
• मौजूदा 32-बिट time_t की सीमा के कारण 19 जनवरी 2038 के बाद समय 1900 में वापस लौटने जैसी स्थिति हो सकती है, इसलिए इस समस्या को अब और टाला नहीं जाएगा
• 64-बिट हार्डवेयर पहले से सुरक्षित है, लेकिन embedded, IoT जैसे लागत-संवेदनशील 32-बिट डिवाइसों में Debian की मांग अभी भी बनी हुई है, इसलिए अग्रिम तैयारी की ज़रूरत पर ज़ोर दिया गया है
• कुल 6,429 पैकेजों में फैले time_t टाइप को एक साथ ABI compatibility टूटने का जोखिम स्वीकार करते हुए समकालिक रूप से बदलने का बड़ा काम किया गया है
• i386, hurd-i386 जैसे कुछ legacy support आर्किटेक्चर अपवाद के रूप में बने रहेंगे, जबकि नए 64-बिट time_t आधारित x86 (i686) आर्किटेक्चर की शुरुआत की संभावना का भी उल्लेख किया गया है

---

Debian का Y2K38 बग के प्रति जवाब: 64-बिट समय में बदलाव

• Debian आने वाली Y2K38 या Unix Epochalypse समस्या से बचने के लिए, समर्थित सबसे पुराने कुछ हार्डवेयर को छोड़कर सभी वातावरणों में 64-बिट समय पर स्विच कर रहा है
• इसके जरिए 19 जनवरी 2038 को होने वाली 32-बिट signed int सीमा से बाहर जाने के कारण समय मान में त्रुटि को रोका जाएगा

Y2K38 और Unix Epochalypse समस्या की पृष्ठभूमि

• Y2K38 समस्या उन Unix सिस्टमों में होती है जो 1 जनवरी 1970 के बाद बीते सेकंड को 32-बिट signed int के रूप में व्यक्त करते हैं; 2038 के बाद overflow होने पर समय 1900 जैसे अतीत में गलत तरीके से लौट सकता है
• यह पहले के Y2K (2000 समस्या) की तरह छोटे डेटा फ़ॉर्मैट चुनने के आर्किटेक्चरल फैसले से पैदा हुई समस्या है
• Y2K के समय डेवलपर्स की अग्रिम तैयारी की वजह से बड़ी अव्यवस्था टाली जा सकी थी
• 64-बिट हार्डवेयर के लिए सॉफ़्टवेयर पहले से सुरक्षित है, लेकिन Debian अभी भी embedded, low-spec, legacy वातावरणों में व्यापक रूप से इस्तेमाल होता है

Debian की मुख्य प्रतिक्रिया

• Debian 13 "Trixie" रिलीज़ से सभी प्रमुख आर्किटेक्चर में 64-बिट time_t को डिफ़ॉल्ट के रूप में लागू किया जा रहा है
• 64-बिट हार्डवेयर पहले से सुरक्षित है, लेकिन 32-बिट प्रोसेसर आधारित embedded डिवाइस और legacy हार्डवेयर में यह समस्या ज़्यादा सामने आती है
• ऐसे उपकरण ऑटोमोबाइल कंट्रोल, IoT, TV, राउटर जैसी लागत-संवेदनशील और बड़े पैमाने पर भेजी जाने वाली श्रेणियों में अभी भी इस्तेमाल हो रहे हैं
• कई नए उपकरण OpenEmbedded, Alpine, Android, Gentoo आदि पर आधारित self-built Linux इस्तेमाल करते हैं, लेकिन Debian-आधारित embedded डिवाइसों का उपयोग आने वाले कई वर्षों तक जारी रहने की संभावना है

लागूकरण और बदलाव

• time_t वेरिएबल संबंधित कोड में 6,429 पैकेजों में फैला हुआ है, इसलिए यह बड़े पैमाने का काम था
• यह बदलाव ABI (Application Binary Interface) compatibility तोड़ सकता है, इसलिए सभी संबंधित लाइब्रेरी और पैकेजों में इसे एक साथ समायोजित किया गया
• मेंटेनेंस टीम के अनुसार, यह काम पूरा हो चुका है और पर्याप्त परीक्षण भी किया जा चुका है

अपवाद और भविष्य की योजना

• i386 पोर्ट (पुराना x86) 32-बिट time_t को जारी रखेगा और मौजूदा बाइनरी चलाने की compatibility के उद्देश्य से बना रहेगा
• i686 आर्किटेक्चर पर 64-बिट समय और आधुनिक ISA (instruction set architecture) लागू करने पर अलग से चर्चा हो सकती है
• hurd-i386 पोर्ट kernel support की कमी के कारण परिवर्तित नहीं किया जाएगा; इसके बजाय hurd-amd64 पर ले जाने की दिशा में काम चल रहा है

डेवलपर्स के लिए संदर्भ

• डेवलपर्स Debian wiki में दिए गए तरीकों से यह टेस्ट कर सकते हैं कि उनका सॉफ़्टवेयर 64-बिट समय वेरिएबल लागू होने पर टूटता है या नहीं
• अधिक जानकारी और तकनीकी दस्तावेज़ Debian wiki पर उपलब्ध हैं

[GN⁺]

Hacker News टिप्पणियाँ

• Steve Langasek ने अपने जीवन के आख़िरी कुछ वर्षों में इस समस्या के समाधान पर ध्यान केंद्रित किया और बड़ी प्रगति करवाई; अब आगे जब भी 64-bit time_t देखूँगा, उनकी याद आएगी
  • यह अच्छी खबर फिर से बताने के लिए धन्यवाद, Steve की कमी महसूस होती है; सोच रहा हूँ कि क्या Joey अब भी Debian गतिविधियों में सक्रिय हैं
• Y2K समस्या (2-अंकीय वर्ष फ़ॉर्मैट के कारण आई 2000 वाली समस्या) के बारे में, उस समय 2 byte बचाना बहुत मूल्यवान था; 70~90 के दशक का software तेज़ी से बदलता था, इसलिए यह उम्मीद नहीं होती थी कि वह 5 साल से ज़्यादा चलेगा; इसे बहुत हल्के में लेने वाला नज़रिया लगता है
  • आज भी 2-अंकीय वर्ष काफ़ी इस्तेमाल होते हैं; उदाहरण के लिए credit card expiry (mm/yy) को छोटा लिखना सुविधाजनक है, इसलिए 2-अंकीय वर्ष फ़ॉर्मैट चलता है; कार्ड की उम्र के लिए यह पर्याप्त है, लेकिन 2100 में conversion समस्या आ सकती है; Y2K की ज़्यादातर दिक्कतें UI से आई थीं (दो-अक्षर वाले text field, +1900 hardcode वगैरह); मैंने जो Y2K bug सीधे देखा था, उसमें एक internet forum 1999 से 19100 पर चला गया था (सिर्फ़ output error); Y2K सिर्फ़ COBOL की समस्या नहीं थी
  • ऐसे मामलों में "premature optimization" उल्टा मददगार होती; अगर तारीख़ को 1900 से offset वाले साधारण int के रूप में रखा जाता, तो और ज़्यादा bytes बचाए जा सकते थे; 3 byte में 1900 से लेकर लगभग 44,000 साल तक, और 2 byte में भी लगभग 2070 तक cover हो जाता
  • लोग जिस बिंदु पर भ्रमित होते हैं, वह 2 byte extra नहीं बल्कि 2 character extra जोड़ने की ज़रूरत थी; COBOL में numeric हो या data, allocation fixed width character size के हिसाब से होता था, इसलिए 4-अंकीय वर्ष रखने के लिए 4 character position चाहिए थीं; ऐसे field size data access, UI, batch file, intermediate file, transfer file आदि पूरे program में hardcode किए जाते थे
  • Y2K से ठीक पहले कुछ परिचितों ने बड़े बैंकों के stock गिरने की उम्मीद में बहुत सारे put option खरीदे थे, लेकिन असल में लगभग कुछ भी बड़ा नहीं हुआ
  • 80 के दशक के आख़िर में COBOL पर काम करते हुए मैंने ऐसा program देखा था जो सिर्फ़ 1-अंकीय वर्ष store करता था; उसका ढाँचा समझाया गया तो अजीब लगा, लेकिन records हर 4 साल में अपने-आप delete हो जाते थे, इसलिए उपयोग में कोई दिक्कत नहीं थी; हमेशा साफ़ रहता था कि कौन-सा वर्ष है
• 64-bit time_t शायद Epochalypse को हल कर देगा, लेकिन सभी system बस सीधे 64-bit seconds पर नहीं जा रहे; ext4 पहले ही 30-bit fractional resolution (nanosecond स्तर) और 34-bit seconds resolution पर बदल चुका है, फिर भी कई सौ साल बाद समस्या दोबारा आएगी; लगता है कि कभी न कभी 64-bit seconds + 64-bit fraction वाले 128-bit timestamp पर ठहराव होगा, और तब मानव इतिहास के पूरे अनुमानित भविष्य को cover किया जा सकेगा
  • 64-bit second time लगभग 585 अरब साल के बराबर है, WolframAlpha calculation result
  • 64-bit fractional resolution भी शायद काफ़ी न हो; Planck time के करीब जाने के लिए 144 bit तक चाहिए होंगे
  • ext4 timestamp के बारे में जिज्ञासा थी; यह भी जानने का मन है कि zfs और btrfs filesystem समय को कैसे handle करते हैं; btrfs शायद 64-bit इस्तेमाल करता होगा, और zfs भी (शायद मैं ext4 के साथ गड़बड़ कर रहा हूँ) वैसा ही होगा, ऐसी उम्मीद है
• कहा जा रहा है कि Debian Y2K38, यानी Unix Epochalypse समस्या को हल कर रहा है, लेकिन असल में i386 को छोड़कर सभी 32-bit port पहले ही time64_t पर migrate हो चुके हैं; सिर्फ़ i386 पुरानी binary compatibility की वजह से अपवाद है, बाक़ी सब, m68k सहित, बदले जा चुके हैं; मैंने खुद m68k, powerpc, sh4, hppa को migrate किया
• time_t variable नहीं, data type है
  • लेख में जो बात आई है, वह Debian wiki पर आधारित है; मूल पाठ में साफ़ लिखा है: “time_t सचमुच हर जगह आता है। 35,960 पैकेजों में से 6,429 के source code में यह आता है। जिन पैकेजों के struct में time_t शामिल है और जो ABI के रूप में expose होते हैं, उन्हें पूरे ABI migration के साथ एकसाथ बदलना पड़ता है”; wiki ने लेख से ज़्यादा स्पष्ट समझाया है
  • “For everything” से मतलब armel, armhf, hppa, m68k, powerpc, sh4 हैं, i386 नहीं; i386 का भविष्य नहीं माना जा रहा और उसका मुख्य उद्देश्य पुराने binary/dynamic library चलाना है, इसलिए उसे तोड़ना नहीं चाहते
  • “Debian 13 Trixie release के बाद लागू होगा” का असली मतलब है कि यह Trixie में शामिल है
• अच्छा होगा अगर command line length limit को भी unlimited/dynamic कर दिया जाए; 96GB memory होने पर भी “argument list too long” error बार-बार आना परेशान करता है
  • kernel को recompile करके command line length (लगभग 100,000 characters) की limit हटाई जा सकती है, stackoverflow संदर्भ, लेकिन यह मूल समस्या का समाधान नहीं लगता; 4k JPEG जितने लंबे argument का उपयोग कहाँ होगा, यह भी सवाल है
  • RLIMIT_STACK value बढ़ा दीजिए; जैसे ulimit -s 4000 का मतलब 4MB stack है; इससे ज़्यादा चाहिए तो /etc/security/limits.conf बदलना होगा और फिर दोबारा login करना होगा
  • इसे Electron में pack करके http post json request से भेज देना चाहिए, ऐसा भी हो सकता है
  • MAX_ARG_STRLEN को redefine करके kernel recompile किया जा सकता है; या फिर बड़े page size वाली machine (जैसे 64k page size वाला RHEL Arm kernel) इस्तेमाल की जा सकती है; लेकिन command buffer की जगह pipe से processes के बीच data भेजना कहीं आसान है
  • file path limit भी कुछ वैसी ही समस्या है; कुछ build system (Debian + python + dh-virtualenv आदि) में path बहुत लंबे हो सकते हैं, इसलिए उन्हें बस allow करना ज़्यादा सुविधाजनक होगा
• 64-bit पर जाने के बाद भी कभी न कभी सीमा आएगी; 292277026596 साल 4 दिसंबर को 3:30:07 PM (UTC) पर मानवता क्या कर रही होगी, यह सोचकर दिलचस्प लगता है
  • शायद तब तक हम ipv6 के पूर्ण adoption की 100वीं वर्षगांठ मना रहे होंगे
  • 5 अरब साल के भीतर सूरज red giant बन जाएगा और पृथ्वी की सतह पूरी तरह वाष्पित हो जाएगी
  • तब तक उम्मीद है कि हम बेहतर calendar system पर जा चुके होंगे, हालाँकि timestamp समस्या फिर भी रहेगी
  • 128-bit time पर चले जाएँगे
  • RFC 2550(Y10K & beyond) लागू किया जा सकता है; यह 1 अप्रैल 1999 को जारी हुआ था
• OpenBSD 5.5 ने यही बदलाव लागू किए हुए 11 साल हो चुके हैं, OpenBSD 5.5 release notes
  • यह उन मामलों में से है जहाँ उसने सबको पीछे छोड़ दिया; 90 के दशक में मैंने देखा था कि OS/2 32-bit API 64-bit time लौटाता है, और मैंने खुद 64-bit time_t के साथ C++ standard library लिखकर इस्तेमाल की थी
  • थोड़ा अलग विषय है, लेकिन ऐसे समय में Linux की जगह OpenBSD पर server बदलने का मन करता है
  • OpenBSD को compatibility की कम चिंता करनी पड़ती है, और users भी बहुत कम हैं, इसलिए बदलाव के समय bug या edge case की संभावना भी कम होती है
• अगर कहा जाए कि “Debian अब काफ़ी पूरा और test हो चुका है, इसलिए Trixie release के बाद switch किया जाएगा”, तो क्या इसका मतलब है कि यह Trixie में लागू नहीं होगा?
  • Trixie release notes में लिखा है कि यह शामिल है, Trixie release notes
• Y2K38 को Unix Epochalypse कहते सुना, यह पहली बार है; नाम प्यारा है, इसलिए शायद फैल सकता है
  • Wikipedia Year 2038 Problem में भी यह नाम आता है; 2017 से मज़ाकिया तौर पर इस्तेमाल होना शुरू हुआ और फैल गया
  • epochalypse-project.org नाम का project भी है
  • “it’s kind of fetch” अभिव्यक्ति में Mean Girls फ़िल्म वाला reference दिखता है
  • Epochalypse तक लगभग 12 साल 5 महीने 22 दिन 13 घंटे 22 मिनट बचे हैं