100 ऑपरेटिंग सिस्टम पर चलने वाला curl

• curl पुराने environments में भी लगातार build और test होता रहे, इसके लिए बदलावों को सीमित रखता है; हाल की pull request में भी 32-bit time_t और legacy platform compatibility को न तोड़ने की शर्त रखी गई
• असली बात बहुत लंबी platform list बनाए रखना नहीं, बल्कि users के upgrade करने पर भी व्यवहार बना रहे — इस ABI/API stability के वादे को निभाना है
• किसी खास operating system के users की संख्या से ज़्यादा अहम यह है कि क्या उसे सच में संभालने और fix करने वाला कोई है; maintainer बचे हों तो कम users वाले platforms भी support होते रह सकते हैं
• curl और libcurl operating systems, CPU architectures और अजीब configurations में “build होकर run होने” की स्थिति बनाए रखने वाले portability-first principle के कारण फैले
• पुराने curl commands के fail होने की मुख्य वजह curl में बदलाव से ज़्यादा hosts और URLs का खत्म हो जाना तथा HTTP से HTTPS में बदलाव जैसी internet environment की बदलती स्थितियां हैं

---

Legacy platforms को न तोड़ने वाले बदलावों का मानदंड

• हाल की curl pull request में बदलावों को git code repository में merge तभी किया जा सकता था जब वे legacy platforms के build या tests को न तोड़ें
• यह बदलाव time_t से जुड़े area में था, और curl पहले से 32-bit time_t type support करता है, इसलिए उस behavior को बनाए रखना जरूरी था
• 32-bit time_t का उपयोग पहले ही सीमित है और 2038 करीब आने के साथ इसकी constraints और बढ़ सकती हैं, लेकिन कई legacy platforms अब भी 32-bit versions पर टिके हैं
• ऐसी मांग contributors का काम कठिन बनाती है, लेकिन curl में इसे बदलाव को अधिक complete और polished बनाने की प्रक्रिया माना जाता है

Compatibility platform count से बड़ा वादा है

• curl project ABI और API stability तथा compatibility बनाए रखने के लिए लगातार प्रयास करता है
• 2000s के मध्य का libcurl इस्तेमाल करने वाला application, application को फिर से compile किए बिना latest libcurl पर upgrade करने पर भी उसी तरह काम कर सकता है
• 2000s की शुरुआत में लिखे गए curl scripts से भी उम्मीद की जा सकती है कि वे latest curl release में लगभग उसी तरह काम करेंगे
• यह compatibility सिर्फ marketing phrase नहीं, बल्कि curl और libcurl द्वारा दिया जाने वाला core principle है
  • Users curl पर भरोसा कर सकते हैं
  • अगर किसी release में bug हो भी, तो सामान्य software upgrade की पीड़ा के बिना नए version पर जाने लायक update देने की कोशिश की जाती है
• जो चीज पहले से अच्छी तरह काम कर रही है, उसे बेवजह न तोड़ने का रवैया maintenance criteria में शामिल है

Support का फैसला maintainer तय करता है

• किसी specific platform के users की संख्या यह तय करने की मुख्य वजह नहीं है कि curl उस platform को support करता रहेगा या नहीं
• अधिक महत्वपूर्ण मानदंड यह है कि काम कौन संभाल रहा है और क्या सच में जरूरी maintenance हो रही है
• अगर कोई contributor किसी platform पर curl के चलते रहने की पुष्टि करता है, तो users कम माने जाने वाले platforms पर भी curl चलता रह सकता है
• कोई platform curl से practically तब गायब होता है, जब उस platform के लिए जरूरी code अब maintain नहीं किया जाता
  • Unmaintained code भी कई साल तक working state में रह सकता है
  • किसी specific platform पर curl अब काम नहीं करता, यह पता लगाने में भी काफी समय लग सकता है
• इसके उलट, users ज्यादा होने वाले platform पर भी अगर उस platform-specific issues को संभालने की इच्छा और knowledge रखने वाले maintainers कम हों, तो maintenance मुश्किल हो जाती है

अलग-अलग environments में फैलने की वजह

• curl और libcurl का बहुत मजबूत focus इस बात पर है कि वे जितने ज्यादा environments में संभव हो, build होकर run हों
• अनोखे या अजीब configurations में भी काम करते रहने का रवैया कई operating systems और CPU architectures में इसके फैलने की एक वजह है
• कई users और companies पुराने, niche या legacy platforms का उपयोग जारी रखते हैं
• उनके लिए curl transfer functionality बनाए रखना, खुद बनाए गए alternative implementation की तुलना में security के लिहाज से अक्सर बेहतर होता है
• अगर functionality तोड़ने की जरूरत नहीं है, तो मौजूदा users को curl पर निर्भर रहने देना बेहतर है — यही निर्णय लागू होता है

Support हटाना धीमे और सार्वजनिक तरीके से होता है

• curl भी कभी-कभी कुछ support हटाता है
• हटाने का मुख्य target उपयोग घटने के कारण धीरे-धीरे गायब हो रही third-party libraries का support होता है, लेकिन support removal अन्य areas में भी हो सकता है
• Support deprecation धीमे, सावधानी से और publicly communicate करते हुए की जाती है
  • जो users जानना चाहते हैं, उन्हें बदलाव पहले से पता चलना चाहिए
  • Users तैयारी कर सकें, या proposal अनुचित लगे तो विरोध कर सकें
• अगर users behavior change detect नहीं कर सकते, तो उसे बदला हुआ नहीं माना जाता
• curl users के लिए बनाया गया है, और अगर users किसी behavior को जारी रखना चाहते हैं, तो वह behavior बनाए रखा जाना चाहिए

पुराने commands fail होने की असली वजह

• Internet protocols और versions समय के साथ आते-जाते रहते हैं
• 2002 में लिखी गई अधिकांश curl command lines आज जस की तस काम न कर सकती हैं
• Failure की वजह curl खुद नहीं, बल्कि उस समय इस्तेमाल किए गए host names और URLs का अब काम न करना हो सकता है
• 2002 के curl command के आज जस का तस न चलने की एक बड़ी वजह HTTP से HTTPS में बदलाव है
• 2002 में TLS या SSL इस्तेमाल करने वाली sites रही हों, तब भी वह आम बात नहीं थी, और उस समय इस्तेमाल किए गए TLS protocol versions आज असुरक्षित माने जा सकते हैं
• Modern TLS libraries और curl, update न की गई पुरानी TLS settings से connection करने से इनकार कर सकते हैं
• अगर 2002 का curl executable संभालकर रखा हो और आज चलाया जाए, तब भी वह modern HTTPS sites से connect नहीं कर पाएगा
  • यह curl में बदलाव की वजह से नहीं, बल्कि transport protocol layer में बदलाव की वजह से है

[GN⁺]

Hacker News की राय

• शानदार उपलब्धि है। Curl सचमुच किसी वरदान जैसा tool है
  Daniel ने 32-bit time_t को compatibility का अहम बिंदु बताया, यह दिलचस्प है। अगर लक्ष्य कई operating systems पर लगातार चलते रहना है, तो यह पूरी तरह समझ में आता है। बस 2038 अब सिर्फ 14 साल दूर है, और curl के पहली बार आने के समय की तुलना में आज के कहीं ज़्यादा करीब है। सोचता हूं कि कब 32-bit time को support करने की मेहनत को अब value न देने लायक माना जाएगा। मेरा अनुमान है Y2K38 date बीतने के करीब 3 महीने बाद, शायद उससे भी ज्यादा देर तक

• Developers जब operations वालों के करीब आते हैं, तो एक बात सीखते हैं। आप पर depend करने वाले जितने ज्यादा होते हैं, बोझ उतना बढ़ता है। Infrastructure और central systems पर अगर बहुत सारी चीजें depend करने लगें, तो वे फुर्ती खो देते हैं, और छोटी-सी change भी सचमुच मुश्किल हो जाती है
  अगर आपके अपने service में backend और frontend हैं और आप दोनों के बीच API को पूरी तरह बदलना चाहते हैं, तो किसे फर्क पड़ता है। बस कर दीजिए।
  लेकिन अगर आप default template के किसी अजीब edge case को सिर्फ इसलिए हटाना चाहते हैं क्योंकि वह “बदसूरत” है, तो आपको 20 पुराने services, 20 आधे-modernized services जिन्हें लोग छूना नहीं चाहते, और उसे इस्तेमाल करने वाले 50 और services देखने होंगे। सिर्फ यह समझने के लिए कि वह change कितना बड़ा काम है, इतना करना पड़ेगा। इस stage पर असली change लागू करने या किसी पेचीदा secret को reverse-engineer करने की बात भी नहीं है।
  मैं इसे glamorous काम नहीं कहूंगा, लेकिन नीचे सब कुछ बदलते हुए भी चमकते मुख्य कलाकारों को लगातार संभाले रखना—बिना किसी को पता चले—roadies या admins को गर्व देता है

• सूची में ऐसी चीजें भी काफी हैं जिनकी 25 साल से ज्यादा समय से कोई release नहीं हुई। SCO, Xenix, OS/2, NextStep पर क्या आज भी current builds बन रहे हैं?
  मैंने इनमें से कुछ चलाए हैं, और जानता हूं कि उन पर भी curl मौजूद है, लेकिन मेरे अनुभव में वह curl हमेशा कम-से-कम 15 साल पुराना version ही था।
  अगर आप कहते हैं कि आप कोई support matrix तोड़ना नहीं चाहते, और उस matrix का बड़ा हिस्सा आखिरी build के बाद 10 साल से भी ज्यादा पुराना है, तो आपको कैसे पता कि वह सच में नहीं टूटा?

  • 25 साल भी शायद काफी generous understatement है
    Xenix के लिए build हो पाएगा या नहीं, मुझे नहीं पता। Target करने लायक सबसे नया GCC 2.7 है, और वह भी पहले से ही प्राचीन version है। Network code को ध्यान में रखें तो और भी ज्यादा। शायद मतलब बस इतना है कि “किसी समय पर यह उन systems पर चलता था”
  • उसकी तुलना में AmigaOS अब भी काफी जीवंत है। Latest release 2021 में आई थी
  • अगर Xenix या OS/2 बदले ही नहीं हैं, तो पुराना Curl build अचानक वहां क्यों टूटेगा?
  • SkyOS भी अच्छा example है। इस point पर यह मानने के बजाय कि कोई सच में SkyOS पर चला रहा है, इसे हटाना ज्यादा safe लगता है

• “बहुत सारे users और companies पुराने, niche और legacy platforms पर अड़े रहते हैं, और हम कुछ नहीं कर सकते” वाली बात पर—ज्यादातर लोग, proprietary closed-source developers तक, ऐसा software बनाते हैं जिसके license की शुरुआत में कुछ ऐसा लिखा होता है: “यह program उपयोगी होने की उम्मीद में distribute किया जाता है, लेकिन बिना किसी warranty के; merchantability या किसी खास purpose के लिए fitness की implied warranty भी नहीं”
  इसकी cost कम होती है।
  दूसरी ओर, मेरे सहित कुछ लोग ऐसा software develop करते हैं जिसमें purpose fitness की guarantee होती है और warranty explicit और absolute होती है।
  यह बहुत महंगा और धीमा होता है।
  अगर कुछ टूटने पर लोग मर सकते हैं, environment खराब हो सकता है, या millions of dollars का नुकसान हो सकता है, तो 30–40 साल तक बहुत धीमे और सावधान developers द्वारा बारीकी से जांचे गए पुराने और niche platforms का इस्तेमाल जारी रखना समझ में आता है।
  कम-से-कम PowerPC पर INTEGRITY में Ada देखते समय मैं खुद से यही कहता हूं

  • उसी एक sentence में आप खुद का विरोध कर रहे हैं
    अगर एक व्यक्ति की मौत millions of dollars के नुकसान में बदल सकती है, तो ऐसे software या platform का इस्तेमाल नहीं करना चाहिए जिसका developer pool “Wilson disease वाले French jugglers की संख्या” जितना छोटा हो

• इसकी popularity की एक वजह शायद permissive license है। मैंने सोचा था कि यह MIT license होगा, लेकिन लगता है थोड़ा अलग है [1]। MIT से मुख्य फर्क क्या है, कोई आसान शब्दों में बता सकता है? Copyright page में detail explanation नहीं है
  [1] https://curl.se/docs/copyright.html

  • MIT license की तुलना में मुख्य extra clause यह हिस्सा लगता है
    “इस notice में शामिल मामलों को छोड़कर, copyright holder की prior written permission के बिना इस software की बिक्री, उपयोग या अन्य dealings को advertise या promote करने के लिए copyright holder का नाम इस्तेमाल नहीं किया जा सकता”
  • Page पर लिखे अनुसार, यह MIT/X11 license से inspired custom license लगता है। MIT/X11 से फर्क बस इतना दिखता है कि warranty disclaimer का शुरुआती हिस्सा छोटा कर दिया गया है। SPDX में इसके लिए अलग entry है [1]
    [1] https://spdx.org/licenses/curl.html
  • लगता है MIT license में BSD 3-Clause license का तीसरा clause मिला दिया गया है

• मुझे लगा था कि सिर्फ Linux versions ही लगभग 100 होंगे, लेकिन सभी Linux versions को एक operating system गिनने के बाद भी 100 हैं—यह हैरान करने वाला है

  • हां, लेकिन वे iOS, iPadOS, watchOS को अलग operating systems गिन रहे हैं, इसलिए असल में करीब 98 operating systems ही हुए। इतना तो खैर… कोई भी कर सकता है…

• कई legacy systems को ध्यान में रखकर code लिखें तो मेरे निजी अनुभव में code आम तौर पर बेहतर हो जाता है
  Naming, types, modularity जैसी अच्छी तरह जानी-पहचानी coding practices का पालन बेहतर होता है, और साफ तौर पर marked हिस्सों को छोड़कर standards compliance भी बेहतर होती है। Abstractions ज्यादा मजबूत हो जाते हैं, खासकर modern platforms पर bugs घटते हैं, और build system भी ज्यादा robust हो जाता है। Future platforms से automatically compatible हो जाता है, या कम-से-कम compatible बनाना बहुत आसान हो जाता है।
  हालांकि अगर आप सिर्फ कुछ legacy systems को target कर रहे हैं, तो अजीब patches और hacks के combination से काम चल सकता है, इसलिए यह बात तब सही न भी हो

• FreeDOS, DR-DOS, MS-DOS को अलग-अलग operating systems के रूप में list करना अजीब है। ये आपस में बहुत मिलते-जुलते हैं, और अलग-अलग Unix families के उलट, practically ABI compatible हैं

  • लगभग ऐसा ही है। जैसा सभी जानते हैं, DR-DOS, MS-DOS, PC-DOS करीब 99% compatible थे, और problem तब होती थी जब बदकिस्मती से आप उस 1% पर पैर रख देते थे। DR-DOS ने MS-DOS को reverse-engineer किया था, और IBM के PC-DOS license ने भी Microsoft को MS-DOS में जो कुछ करने की access थी, वह सब access नहीं दी थी
  • DR-DOS, MS/PC-DOS ABI compatibility वाला CP/M का सीधा descendant है, इसलिए यह साफ तौर पर अलग operating system है। FreeDOS भी ऐसा ही है। Internals देखें तो हर एक में पर्याप्त फर्क हैं
  • OPENSTEP और NeXTSTEP को भी अलग operating systems के रूप में list किया है…

• फिर भी लोग इसे Rust में फिर से लिखना चाहते हैं। क्या Rust वास्तव में उन सभी architectures और operating systems को target कर सकता है?

  • कोई curl को फिर से क्यों लिखना चाहेगा? C इस्तेमाल करने में आखिर इतनी क्या problem है?

• संबंधित पढ़ाई: curl कैसे पैदा हुआ और उसका history क्या रहा, इस पर लेख (1)
  (1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...