मैं Red Hat (Enterprise Linux) से अलग हो गया हूं

 (jeffgeerling.com)
1 पॉइंट द्वारा GN⁺ 2023-06-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CentOS के बंद होने के बाद भी Red Hat ecosystem में बने रहे Jeff Geerling ने RHEL source access में बदलाव के चलते Enterprise Linux के official support को बंद कर दिया
  • नई policy RHEL rebuild के लिए जरूरी source flow को बदलती है, जिससे Rocky Linux और AlmaLinux जैसे downstream distributions की बुनियाद हिलती है
  • GPL के तहत source को paid subscription के पीछे रखा जा सकता है, लेकिन redistribution करने पर subscription cancel किया जा सकता है—ऐसी terms कानूनी और community trust से जुड़ी समस्याओं तक जा सकती हैं
  • developers और EPEL/Fedora maintainers पर Red Hat Developer Account और 16 RHEL licenses के हिसाब से testing infrastructure को फिर से design करने का बोझ आ गया है
  • Geerling का मानना है कि Red Hat open-source community में कमाया trust profit के कारण खो रहा है, और Rocky Linux व AlmaLinux ने कहा है कि वे अपने-अपने survival paths ढूंढेंगे

CentOS बंद होने के बाद फिर उभरा RHEL source access का मुद्दा

  • Red Hat ने 2 साल पहले व्यापक रूप से इस्तेमाल होने वाले free Enterprise Linux distribution CentOS को बंद कर दिया था
  • CentOS user community को Red Hat के काम का बिना भुगतान इस्तेमाल करने वाले “freeloaders” कहा गया, और Geerling खुद को भी उस community का हिस्सा मानते हैं
  • CentOS open-source developers, Linux kernel contributors और software developers के लिए testing और builds का आधार था
  • Geerling जोर देते हैं कि Red Hat भी अपने products Linux के ऊपर बनाता है, जिसे उसने न तो बनाया है और न ही own करता है

2020 का वादा और downstream distributions को नुकसान

  • बताया गया है कि 2020 में CentOS बदलाव के बाद भी Red Hat ने git sources को public रखना जारी रखने का वादा किया था
  • यह बदलाव CentOS से भी लंबे समय से maintain हो रहे RHEL downstream distribution SDL/PUIAS जैसे projects के लिए भी बड़ी मुश्किलें पैदा कर रहा है
  • Geerling का मानना है कि मौजूदा हालात में ऐसे distributions collateral damage झेल रहे हैं

Rocky Linux और AlmaLinux ने बड़े पैमाने पर पलायन रोका था

  • CentOS बंद होने के बाद भी Geerling के Red Hat ecosystem में बने रहने की दो वजहें थीं
    • कुछ Red Hat employees ने open-source user community पर हमला करने के बजाय “हम बेहतर कैसे कर सकते हैं” पूछते हुए बातचीत की कोशिश की
    • Rocky Linux और AlmaLinux सामने आए और developers के लिए stable open-source work targets बन गए
  • हालांकि, ये दोनों distributions Red Hat के source code share करने की संरचना पर निर्भर थे

पुराना RHEL source release flow

  • पुराने तरीके को इस क्रम में समझा जा सकता था
    • Red Hat Linux की एक copy लेता है
    • उसे Red Hat Enterprise Linux बनाने के लिए अपने बदलाव जोड़ता है
    • नया version release करता है
    • शुरू से build करने के लिए जरूरी data वाले source code repository को update करता है
  • open source में source खुला होता है और एक-दूसरे का काम share करके सभी को लाभ मिलना ही core idea है
  • Linux द्वारा इस्तेमाल किया जाने वाला GPL license source sharing को कानूनी रूप से आवश्यक बनाता है
  • माना जाता है कि इस sharing के बिना Debian, Arch, Mint, Ubuntu, PopOS, Fedora जैसे असंख्य Linux distributions का अस्तित्व मुश्किल होता

paid subscription के पीछे गया source और terms पर विवाद

  • Red Hat ने source code को paywall के पीछे रखने का फैसला किया
  • Geerling मानते हैं कि यह तरीका तकनीकी रूप से GPL के तहत संभव है
  • लेकिन वे आलोचना करते हैं कि lock किया जा रहा code का बड़ा हिस्सा दूसरे लोगों के open-source code पर आधारित है, इसलिए यह असम्मानजनक और परेशान करने वाला तरीका है
  • बड़ा मुद्दा Red Hat की मौजूदा subscription terms हैं
    • Red Hat कहता है कि अगर users source code download कर उसे redistribute करते हैं, तो वह account cancel कर सकता है
    • अगर कोई Red Hat subscription से source download कर Rocky Linux का नया version build करे और Red Hat उस subscription को cancel कर दे, तो Geerling के अनुसार यह court battle देखने लायक मामला होगा
  • यह अनिश्चित है कि community IBM के powerful lawyers का सामना करने के लिए पैसा जुटा पाएगी या नहीं, लेकिन Oracle को ऐसा कर सकने वाले player के रूप में बताया गया है
  • Red Hat की कार्रवाई Linux GPL terms की legality की सीमा के काफी करीब है, और संबंधित analysis के रूप में Software Freedom Conservancy का लेख दिया गया है

downstream distributions पर दबाव डालने का आकलन

  • Geerling को दिख रहे संकेत इस ओर इशारा करते हैं कि Red Hat Rocky, Alma, Oracle Linux जैसे downstream distributions पर दबाव डालना चाहता है
  • उनका मानना है कि Red Hat इन distributions के users को असुरक्षित महसूस कराकर Red Hat subscription की ओर ले जाना चाहता है
  • वे यह cynical interpretation भी जोड़ते हैं कि IBM को संतुष्ट करने के लिए short-term profit lock-in हेतु यह कदम जरूरी समझा गया होगा

open-source company image और आज की तुलना

  • Red Hat पहले एक rebellious company थी और Gandhi quote वाले ads इस्तेमाल करते हुए खुद को open source के जरिए मौजूदा proprietary software companies को हिलाने वाले underdog की तरह position करती थी
  • आज Red Hat large enterprises में Linux चलाने के लिए लगभग default option जैसी स्थिति में है
  • Geerling मानते हैं कि Cory Doctorow ने दूसरी company के बारे में platform decline पर जो phrase लिखा था, वह Red Hat पर भी फिट बैठता है
    • अर्थ यह है कि platform पहले users के साथ अच्छा व्यवहार करते हैं, फिर business customers के लिए users का शोषण करते हैं, और अंत में खुद value reclaim करने के लिए business customers तक का शोषण करके मर जाते हैं
  • उनके लिए Red Hat open-source community में कमाई गई goodwill को Linux के संदर्भ में profit के कारण छोड़ रहा है

developers और maintainers पर आया practical बोझ

  • Geerling जैसे developers, EPEL repository maintainers, Fedora maintainers long-term impact को लेकर चिंतित हैं
  • उन्हें Red Hat Developer Account में sign up करके testing के लिए 16 RHEL licenses लेने की सलाह दी गई है
  • Geerling का मानना है कि इस तरीके के कारण testing infrastructure और automation को Red Hat licenses के हिसाब से फिर से बदलना पड़ेगा
  • Debian, Ubuntu, FreeBSD, Rocky Linux ऐसी प्रक्रिया की मांग नहीं करते
  • Red Hat employees के CentOS Stream इस्तेमाल करने को कहने पर भी वे विरोध करते हैं
    • Rocky और Alma Linux को करोड़ों बार नहीं, बल्कि लाखों बार download किए जाने की वजह है
    • वे CentOS Stream को CentOS का replacement नहीं मानते

Enterprise Linux support बंद और Ansible को लेकर अनिश्चितता

  • Geerling ने पिछले शुक्रवार से अपने सभी work में Enterprise Linux official support हटाना शुरू कर दिया
  • Ansible को लेकर भी उनसे सवाल पूछे जा रहे हैं
    • Ansible को वे Red Hat Ansible Automation Platform, यानी IBM का product बताते हैं
    • वे नहीं सोचते कि Ansible access lock करने की कोशिश करेगा, लेकिन इस संभावना पर पल भर के लिए भी विचार करना पड़े, यही स्थिति असामान्य है
  • उनका रुख है कि वे ऐसे ecosystem पर कुछ build नहीं करना चाहते जहां open-source users को freeloaders कहा जाता है और release cycle के बीच बिना किसी warning के लगातार दो बार बड़े पैमाने पर disruption होता है

Rocky और Alma ने रास्ता निकालने की घोषणा की

  • Geerling नहीं मानते कि यह घटना long term में Red Hat के लिए मददगार होगी
  • यह स्थिति तीनों समूहों के लिए दुखद बताई गई है
    • वे users जो CentOS का उपयोग कर Red Hat ecosystem में लोगों को लाने वाले tools develop कर रहे थे
    • Red Hat, जो कभी open source के लिए लड़ने वाली company थी लेकिन अब अपने ही source code पर barriers लगा रही है
    • वे लोग जिन्हें Red Hat ecosystem के भीतर रहकर license issues और open-source community के departure को संभालना है
  • Rocky Linux और AlmaLinux ने अलग-अलग आगे बढ़ने का तरीका खोजने की घोषणा की है
  • Geerling कहते हैं कि वे Rocky Linux और AlmaLinux को best-effort basis पर support करना जारी रखेंगे, लेकिन आगे Enterprise Linux support कर पाएंगे इसका उन्हें भरोसा नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-06-27
Hacker News की राय

  • मुझे नहीं लगता कि इस तरह की भावनात्मक और तथ्यों के मामले में ढीली आवेगपूर्ण टिप्पणी ज़्यादा रचनात्मक है
    मैं Red Hat के इस फैसले से नाखुश हूँ, और Red Hat जिस दिशा में जा रहा है उसे लेकर भी बहुत चिंतित हूँ। 10 साल से भी ज़्यादा समय में पहली बार मैं अपने काम और उन कंपनियों के लिए, जिनमें मैं निर्णय लेता हूँ, आधार बनने वाले ecosystem की फिर से समीक्षा कर रहा हूँ
    यह मानना कठिन है कि Red Hat का नेतृत्व अब open source की सचमुच बहुत परवाह करता है, और भले ही करता हो, उसने यह दिखा दिया है कि अल्पकालिक revenue बढ़ाने के लिए open source को नुकसान पहुँचाया जा सकता है
    लेकिन जहाँ तक मुझे पता है, freeloaders शब्द का इस्तेमाल एक ही व्यक्ति ने किया था, और संदर्भ से यह भी साफ़ नहीं है कि वह किसकी ओर इशारा कर रहा था, या वह उसकी निजी राय थी या कंपनी की राय। यह भी नहीं लगता कि वह उन लोगों की बात कर रहा था जो CentOS का इस्तेमाल करते हुए वास्तव में community में योगदान दे रहे थे
    किसी भी बड़े संगठन में ऐसे लोग ज़रूर होते हैं जिनकी राय पूरे संगठन की राय नहीं होती; एक व्यक्ति की भाषा से पूरे संगठन को रंग देना अनुचित और अलाभकारी है
    मुझे समझ नहीं आता कि यहाँ लक्ष्य क्या है। क्या बात को अच्छे-बुरे की धुरी पर ध्रुवीकृत करके ऐसा माहौल बनाना है, जहाँ हर कोई सिर्फ़ अपने खेमे का बचाव करे क्योंकि “दूसरी तरफ़” वाले उसके शब्दों और फैसलों को पकड़कर हमला कर सकते हैं?
    मुझे OP का content काफ़ी पसंद है, लेकिन थोड़ा चिंता होती है कि वह YouTube की सफल फ़ॉर्मूला वाली भावनात्मक शैली, ख़ासकर गुस्सा और आक्रोश भड़काने वाले तरीक़े, में बहुत गहराई तक चला गया है, और इस मुद्दे को भी ज़रूरत से ज़्यादा भावनात्मक ढंग से ले रहा है

    • Red Hat ने वास्तव में ऐसा कहा या नहीं, इससे अलग, क्या इसे सीधे-सीधे मुफ़्तख़ोरी नहीं कहा जा सकता?
      सभी CentOS user मुफ़्तख़ोर नहीं थे, और उसके वैचारिक उत्तराधिकारी distribution के user भी नहीं। लेकिन CentOS user का बड़ा हिस्सा CentOS या व्यापक free/open source software community को किसी भी रूप में कुछ लौटाकर नहीं देता था
      और उनमें से काफ़ी लोग Red Hat EL के सारे फ़ायदे चाहते थे, लेकिन उसके लिए पैसे नहीं देना चाहते थे, इसलिए CentOS इस्तेमाल करते थे
      यह काफ़ी हद तक मुफ़्तख़ोरी जैसा लगता है। copyleft open source license मुफ़्तख़ोरी की अनुमति देते हैं [1], लेकिन Red Hat का source code access सीमित करना भी अनुमत है। जब तक वह अपने ग्राहकों के प्रति license obligations पूरी कर रहा है, तब तक इसमें समस्या नहीं है
      Red Hat free/open source ecosystem में बहुत बड़ा पैसा लगा रहा है, और जिन ग्राहकों के पास भुगतान की पर्याप्त क्षमता है उनसे subscription fee दिलाने की कोशिश पूरी तरह उचित है। बाकी user के लिए और भी बहुत से विकल्प हैं
      [1] अगर license non-copyleft होता, तो Red Hat पर source code देने की कोई बाध्यता नहीं होती
    • Red Hat ने उन्हें freeloaders नहीं कहा था; यह The Register के लेख में इस्तेमाल किया गया शब्द था
      “ज़्यादातर clone हटाने का समय बीत जाने के बाद, Red Hat ने अपने paid flagship product का आधिकारिक मुफ़्त संस्करण भी समाप्त कर दिया। इसके बजाय उसने मुफ़्त test version देने की ओर रुख किया और community participation जैसी सकारात्मक लगने वाली भाषा के साथ इसकी घोषणा की। असल में, Red Hat के नज़रिए से यह उन लोगों के झुंड को काटने जैसा था जिन्हें मुफ़्तख़ोर माना जा सकता है। इस कदम में developers के लिए RHEL की मुफ़्त production deployment भी शामिल थी, लेकिन यह अधिकतम 16 मशीनों तक सीमित थी”
      https://www.theregister.com/2023/06/23/red_hat_centos_move/
    • Geerling अपने content को सूची के शीर्ष पर चढ़ाने में बेहद माहिर है
      Red Hat पर उसकी दूसरी पोस्ट के समय मुझे भी ऐसा ही लगा था। वह कभी-कभी दिलचस्प चीज़ें पोस्ट करता है, लेकिन ज़्यादातर समय YouTube-स्टाइल marketing बहुत ज़्यादा लगती है
      मुझे पता है कि वह metrics पाने के लिए जानबूझकर ऐसा करता है, और उम्मीद है कि यह उसके लिए काम करता हो और उसे वही audience मिलती हो जो वह चाहता है। यह देखते हुए कि उसने अपना तरीका नहीं बदला, शायद ऐसा ही है
    • इसे “एक व्यक्ति” कहना ठीक नहीं होगा; CentOS user को मुफ़्तख़ोर मानने की भावना IBM के भीतर और बाहर काफ़ी व्यापक थी
      मुझे वह शुरुआती घोषणा याद है जिसमें CentOS को ख़त्म करके उसकी जगह CentOS Stream लाने की बात कही गई थी। कई IBM, यानी Red Hat, कर्मचारियों ने इस बदलाव का बचाव करते हुए CentOS user को ऐसे लोगों की तरह पेश किया जो paid product मुफ़्त में इस्तेमाल कर रहे थे
      Hacker News, Reddit वगैरह पर भी बहुत लोग इसी तरह इसका बचाव कर रहे थे। मैं नहीं चाहता कि इतिहास को फिर से लिखा जाए
    • बल्कि मुझे लगता है कि ऐसी भावनात्मक प्रतिक्रिया ज़रूरी है। शिक्षा का बुनियादी सिद्धांत है कि जब व्यवहार और परिणाम के बीच दूरी कम होती है तो conditioning बेहतर होती है
      उन्हें हर बार backlash से डरना चाहिए
      लोगों को सचमुच छोड़कर जाने के लिए तैयार रहना होगा। नहीं तो Reddit की तरह आख़िर में सब कुछ फिर पहले जैसा ही चलता रहेगा

  • मैं Jeff की स्थिति से सहानुभूति रखता हूँ, लेकिन लगता है कि पिछले हफ़्ते में यह इस विषय पर उसकी तीसरी पोस्ट है जो HN के पहले पेज पर पहुँची है
    अब लगता है कि इस पत्थर से और ख़ून नहीं निकलेगा। Jeff चाहे अपनी गेंद उठाकर घर चला जाए, यह उसका अधिकार है, और सच कहें तो Red Hat का भी
    लेकिन मुझे लगता है कि यह मामला अब “ध्यान देने योग्य ख़बर” वाले चरण से आगे निकल चुका है, और Jeff की झुंझलाहट भरी एक और पोस्ट से बातचीत आगे नहीं बढ़ेगी

    • निजी तौर पर मुझे यह ठीक लगता है। open source दुनिया में यह बड़ी घटना है, और कई साल बीत जाने के बावजूद CentOS और RHEL के बारे में ज़्यादा न जानने वाले नज़रिए से देखें तो ऐसी पोस्ट कुछ हद तक समझ बढ़ाती हैं
      तीन पोस्ट की ज़रूरत थी या नहीं, या क्या तीनों को HN के पहले पेज पर जाना चाहिए था, यह नहीं जानता, लेकिन कुल मिलाकर यह मुझे इतना बड़ा मुद्दा भी नहीं लगता। लोगों ने वैसे ही vote किया
    • मुझे नहीं लगता कि इस पोस्ट का लक्षित पाठक Hacker News है
    • Geerling आख़िर है कौन, इस तरह की प्रतिक्रिया भी समझ में आती है ;-)
      मज़ाक अपनी जगह, लेकिन कुछ दिन पहले मुझे भी उसे Google करना पड़ा था। आजकल मैं tech YouTuber चैनलों को ज़्यादा follow नहीं करता

  • Jeff के शब्दों में कहें तो, पुराना तरीका यह था कि Red Hat Linux की एक कॉपी लेकर उसमें वह “magic source” जोड़ता था जिससे वह Red Hat Enterprise Linux बन जाती थी, फिर नया version जारी करता था, और शुरुआत से build करने के लिए ज़रूरी सारा data source code repository में update कर देता था
    कुछ बातें और जोड़ें तो, अब वह magic source वाला हिस्सा गायब हो चुका है। कोई secret source या black-box equipment नहीं है; सब कुछ CentOS Stream में सार्वजनिक है
    Red Hat अब company firewall के पीछे RHEL development नहीं करता, बल्कि CentOS Stream में खुलकर सारा काम करता है। security CVE एक अपवाद है, लेकिन व्यवहार में embargo हटते ही वह CentOS Stream और RHEL, दोनों में एक साथ आता है
    आखिरकार यह तर्क CentOS Stream को जानबूझकर नज़रअंदाज़ करने से पैदा होता है। RHEL clones बस CentOS Stream को track कर सकते हैं, और CentOS Stream के CI/CD flow जैसे “secret source” की भी नकल कर सकते हैं
    आज RHEL को clone करने की प्रक्रिया पहले के किसी भी समय से कहीं ज़्यादा आसान हो गई है

    • दो बातें दिमाग में आती हैं
      कुछ हफ़्ते पहले की तुलना में अब bugs तक एक जैसे रखते हुए clone बनाने में ज़्यादा मेहनत चाहिए। और यह काम Red Hat के समानांतर करना पड़ता है, इसलिए effort का duplication होता है
      और यह भी कि यह बदलाव 9.x release cycle के बीच में Rocky और AlmaLinux पर मजबूरी में थोपा गया, और उससे पहले CentOS को बंद करना भी 8.x release cycle के बीच में 24 घंटे से भी कम notice पर किया गया था—इसे देखकर यह महसूस करना मुश्किल है कि यह बदलाव सिर्फ “CentOS और RHEL development को बेहतर बनाने” के लिए किया गया था
      अगर सच में वही मकसद होता, तो community को planning का मौका देने के लिए कम से कम कुछ हफ़्ते, और बेहतर हो तो कुछ महीने पहले announce करना चाहिए था। लेकिन लगातार दो बार सब पर अचानक हमला जैसा हुआ
    • पहले ही कह दूँ, Jeff पर Red Hat का कोई कर्ज़ नहीं है, और किसी भी वजह से, या बिना वजह भी, उसे RHEL “support” बंद करने की पूरी आज़ादी है
      लेकिन “Linux की एक कॉपी ले लेते हैं” वाला वाक्य Red Hat जो कुछ RHEL releases बनाने के लिए करता है, उसका बहुत ज़्यादा सरलीकरण कर देता है
      Red Hat सैकड़ों, हज़ारों upstreams को जोड़कर RHEL बनाता है, उनमें से कई में योगदान भी देता है, पूरे stack को साथ में test करता है, और partners को उस पर software certify करने में मदद करता है
      यह सही है कि Red Hat Linux kernel का “मालिक” नहीं है, लेकिन उसने लंबे समय तक kernel development में बहुत बड़ा योगदान दिया है। RHEL सिर्फ kernel भी नहीं है, और न ही कोई एक single upstream है। यह हज़ारों packages को साथ test करके support product के रूप में जारी किया गया परिणाम है
      Red Hat जिस चीज़ की रक्षा करना चाहता है, वह किसी एक project या कई projects के source code नहीं, बल्कि उन सभी हिस्सों को जोड़कर बनाई गई value है। संयोग से companies, competitors, और community भी source code खुद नहीं, बल्कि वही value चाहते हैं
      सब लोग असल में समय के एक खास बिंदु के उस snapshot को चाहते हैं जिस पर व्यावहारिक रूप से standard के रूप में सहमति बन चुकी है। क्योंकि पूरी community किसी दूसरे viable standard पर सहमत नहीं हो पाई है, जिसे applications व्यापक रूप से target कर सकें। उस standard का एक नाम है, और वह RHEL है, और वह Red Hat का है
      चाहें तो आप सारे pieces लेकर खुद assemble कर सकते हैं। लेकिन Red Hat के अलावा किसी और को उसे औपचारिक या अनौपचारिक रूप से RHEL के रूप में certify करने का अधिकार नहीं है
      अगर इससे गुस्सा आता है, तो मैं ईमानदारी से सलाह दूँगा कि Debian को वह standard बनाने की कोशिश करें जिसे सब लोग certification target मानें। या फिर Red Hat से बड़ी company बनाकर वह जगह हासिल करें जो आज RHEL के पास है
      Mark Shuttleworth कई सालों से Red Hat के RHEL business model की आलोचना करते रहे हैं, लेकिन अब Ubuntu Pro में 5 साल बाद package updates को पीछे धकेलना और Universe तथा Main repository updates के लिए पैसे लेना देखें तो यह काफ़ी हद तक वैसा ही लगता है
    • CentOS Stream के RHEL का upstream होने की बात को जानबूझकर नज़रअंदाज़ किया जा रहा है। CentOS, RHEL का downstream था
      Oracle Linux, Alma Linux, Rocky Linux—ये सभी RHEL के downstream हैं
      आप पूरे दिन यह कहते रह सकते हैं कि CentOS Stream, RHEL से कितना मिलता-जुलता है। आप यह भी कह सकते हैं कि अब उसका upstream बन जाना आपके लिए कोई बड़ी बात नहीं है
      लेकिन व्यवहार में upstream है या downstream, यह बहुत से users और companies के लिए महत्वपूर्ण है
      IBM का open source code तक पहुँच रोकने की कोशिश करना, और subscribers को उसी open source code को redistribute करने से रोकने की कोशिश करना भी महत्वपूर्ण है
      IBM उस open source ecosystem को गंभीर नुकसान पहुँचा रहा है जिससे वह खुद फ़ायदा उठाता है
    • कुछ हफ़्ते पहले source RPM सार्वजनिक रूप से उपलब्ध कराए जाते थे, इसलिए उस समय RHEL cloning ज़्यादा आसान थी

  • वह tweet लिखने वाला मैं ही हूँ
    Mike, जिसने Mastodon पर सबसे पहले इस बात की ओर ध्यान दिलाया था, उसने अभी अपना tweet—या कहें toot—update किया है और बताया है कि Red Hat की ओर के contacts ने पुष्टि की है कि यह एक bug है
    developer subscription अब भी 16 servers तक सीमित है
    https://twitter.com/fareszr/status/1673145072714665984

  • RHEL के पास driver ecosystem में एक बड़ा फायदा है, जिसका उन्हें खुद भी शायद पूरा अंदाज़ा न हो। मुझे लगता है कि वे इसे खराब करने का जोखिम उठा रहे हैं
    जब इंडस्ट्री ने Linux को गंभीरता से लेना शुरू किया, तब RHEL प्रमुख distribution था। नतीजतन संयोग से RHEL और उसके derivative distributions commercial hardware drivers के मुख्य target बन गए
    उदाहरण के लिए, कम-ज्ञात low-latency network cards या packet capture cards को दूसरे systems की तुलना में RHEL derivative distributions पर चलाना आसान होता है। ऐसी hardware बनाने वाली कंपनियों से बात करें तो वे RHEL family को default standard मानकर चलती हैं
    driver support की वजह से Red Hat derivative distributions commercial deployment का standard बन गए। लेकिन Red Hat ने वह deployment scale अपने पास नहीं रखा। असली deployment volume hedge funds, prop trading firms, और oil exploration grids में लगे CentOS/Rocky/Alma पक्ष में है
    मेरी नज़र में यही driver स्थिति Red Hat ecosystem की असली value है। user space थोड़ा बिखरा हुआ है और package manager भी खास प्रभावशाली नहीं है। फिर भी drivers बिना खास दिक्कत के चलते हैं, इसलिए लोग RHEL derivative distributions deploy करते हैं
    अगर Red Hat derivative distributions को खत्म कर सकता है, तो वह एक turning point शुरू करेगा जिसके बाद इंडस्ट्री RHEL family को standard driver target की तरह देखना बंद कर देगी
    जो कंपनी 5,000 servers पर CentOS चला रही थी, वह अचानक प्रति server सालाना 350 डॉलर नहीं देगी। वह Debian पर चली जाएगी और migration का दर्द सह लेगी। commercial driver culture भी जल्दी पीछे-पीछे आ जाएगा। ऐसा cultural change कुछ सालों में नहीं, कुछ दिनों में हो सकता है
    मुझे Red Hat का per-server billing model भोला लगता है। सालाना 350 डॉलर में सिर्फ बिना support वाला license मिलता है। कुछ revenue छोटे businesses और पारंपरिक service expectations वाली कंपनियों से आ सकता है, लेकिन क्या सचमुच मौका वहीं है
    data center बनाते समय आप हर server को PXE boot कराना चाहते हैं। इससे आप नया PXE image बनाकर और hosts को reboot करके grid के लिए system image बदल सकते हैं। यह setup तैयार करना झंझट भरा है, और अच्छा होगा अगर Red Hat कोई अच्छा off-the-shelf solution दे
    site के हिसाब से 100 servers पर सालाना 2,000 डॉलर, जिसमें PXE device का direct support भी शामिल हो, ऐसा model काफी हो सकता है। Red Hat अगर यह रास्ता चुने तो derivative distributions के साथ सह-अस्तित्व रख सकता है। अगर इसे appliance बना दिया जाए, तो यह firewall या network switch की तरह एक आम product बन सकता है

    • अगर आप बताना चाहें, तो मैं जानना चाहूँगा कि किस वजह से ज्यादा specialized hardware drivers RHEL पर बेहतर target किए जाते हैं, build होते हैं, या चलते हैं
      मेरी समझ यह है कि RHEL मूलतः उसी kernel पर patches लगाता है लेकिन interface में बड़े बदलाव नहीं करता। इसलिए source-form drivers या कुछ binary blob drivers भी आम kernel की तरह ही लगभग build और run होने चाहिए
      यह बात कि driver developers RHEL/CentOS इस्तेमाल करते हैं, इसलिए उस पर behavior verified है — इसके अलावा क्या मैं कुछ मिस कर रहा हूँ

  • OP ने जो Software Freedom Conservancy का RHEL और GPL का कानूनी विश्लेषण लिंक किया, वह सबसे दिलचस्प लगा
    https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...

    • यह कहना मुश्किल है कि यह बहुत अच्छा analysis है, क्योंकि इसमें सीमा से बचकर निकलने जैसी अस्पष्ट भाषा है
      आप किसी और के GPL code को अपने product में इस्तेमाल करके पैसे ले सकते हैं। अगर कोई मांगे, तो आपको GPL source और GPL code से निकला अपना source “प्रकट” करना होगा। यहाँ प्रकट करने का मतलब यह नहीं कि आपको public download page रखना है या उसे आसानी से उपलब्ध कराना है; मतलब सिर्फ इतना है कि मांगने पर देना होगा
      आप DVD, flash drive या किसी भी पसंदीदा माध्यम से भेज सकते हैं, और माध्यम की लागत जितना शुल्क भी ले सकते हैं। यानी source को आसान बनाना ज़रूरी नहीं, और built product को मुफ्त देना भी ज़रूरी नहीं
      GPL की सीमा के भीतर भी बहुत कुछ किया जा सकता है। अगर IBM/Red Hat उसी के भीतर काम कर रहे हैं, तो फिर समस्या क्या है
      GPL के बिना भी ऐसा संभव है। उदाहरण के लिए SQLite3 public domain है, लेकिन SQLite Consortium मौजूद है, और मेरा अनुमान है कि इससे D. R. Hipp और उनके कर्मचारियों को काफी अच्छी आय होती होगी। forks से लगभग कोई प्रतिस्पर्धा नहीं है, क्योंकि SQLite3 को भरोसेमंद तरीके से fork करना बहुत मुश्किल है, और इसकी वजह यह है कि बेहतर test suite proprietary और secret है
      कंपनियों के लिए open source एक tool है। व्यक्तियों के लिए भी open source एक tool है। अगर कोई युवा अभी शुरुआत कर रहा हो और उसके पास संसाधन कम हों, तो वह उपयोगी software को open source बनाकर प्रतिष्ठा कमा सकता है और बेहतर नौकरी या अपना business शुरू करने के अवसर पा सकता है
    • इस पर कल चर्चा हुई थी: https://news.ycombinator.com/item?id=36452101

  • IBM के MBA लोगों ने आखिरकार Red Hat पर कब्जा कर लिया है
    तरीका वही है: चाहे लंबे समय में उल्टा असर हो, फिर भी 1 डॉलर और निचोड़ लो। मुझे पता था कि यह कभी न कभी होगा, और सच कहूँ तो हैरानी इस बात की है कि इतना समय लग गया

    • ऐसे MBA लोग annual bonus के पीछे लगे होते हैं
      आजकल कई कंपनियों में यही दिखता है। ऐसे projects शुरू होते हैं जो कहीं नहीं पहुँचते या जल्द ही cancel हो जाते हैं, bonus मिल जाता है, लोग चले जाते हैं, और चक्र फिर शुरू हो जाता है
      लंबे समय की कमाई के लिए टिके रहने वाला ही बेवकूफ बनता है। या उल्टा देखें, तो शायद workers ने आखिरकार corporate secret समझ लिया है
    • यह भावना बहुत सुनने को मिलती है, लेकिन Red Hat के अंदर जो दिखता है और जो public news से पता चलता है, उसके आधार पर इस दावे को सहारा देने वाला evidence नहीं है
      लगता है कि इस फैसले में लंबे समय से काम कर रहे बहुत से लोग शामिल थे। अगर सच बिल्कुल उल्टा हो तो

  • “इस बात को भी नज़रअंदाज़ करो कि Red Hat अपना product उस Linux के ऊपर बनाता है जिसे उसने न बनाया, न own किया” जैसी बात मुझे यह भूलती हुई लगती है कि Linux की लगातार सफलता का एक बड़ा हिस्सा Red Hat की देन है
    Red Hat ने compliance को आगे बढ़ाया और उस दिशा में development को fund किया, जिससे government contracts में प्रतिस्पर्धा करना संभव हुआ, और Linux development में Red Hat का सीधा समर्थन भी बहुत बड़ा रहा है
    बेशक Linux की सफलता की एकमात्र वजह Red Hat नहीं है, लेकिन यह साफ है कि RHEL की सफलता ने Linux को data center के लिए उपयुक्त बनाने में बड़ी भूमिका निभाई

    • ज़रूरी नहीं। data center में Ubuntu और Debian, Red Hat से कहीं ज्यादा व्यापक रूप से इस्तेमाल होते हैं
      Linux grassroots distribution के जरिए लोकप्रिय हुआ, और उसके बाद कंपनियों ने उससे पैसा कमाया। आजकल एक narrative बन गया है कि कंपनियों ने शुरू से ही खेल चलाया, लेकिन यह सच नहीं है

  • Stream, CentOS परिवार का, यानी Alma या Rocky जैसे विकल्प का विकल्प क्यों नहीं बन सकता, इसके कुछ कारण हैं
    पहला, Stream को EL-compatible packages build करने के आधार के रूप में इस्तेमाल नहीं किया जा सकता। इस बात की कोई गारंटी नहीं है कि Stream ABI compatibility नहीं तोड़ेगा
    दूसरा, Stream में कई सालों तक चलने वाला लंबा support cycle नहीं है, इसलिए इसे एक स्थिर system के रूप में इस्तेमाल नहीं किया जा सकता। बेशक, Red Hat की paid license support की ज़रूरत नहीं है, और bug reports व testing के ज़रिए मदद करने के लिए तैयार एक बड़ा community मौजूद है

    • यह कहना गलत है कि ABI compatibility न टूटने की कोई गारंटी नहीं है
      सख्ती से देखें तो यह कहा जा सकता है कि कोई गारंटी नहीं है, लेकिन ऐसा breakage भविष्य के RHEL release को भी तोड़ देगा, इसलिए वह bug है
      support period 5 साल है
    • यह जानना दिलचस्प होगा कि packages आम तौर पर Stream में कितने समय तक रहते हैं, उसके बाद EL में जाते हैं

  • Jeff सहित किसी भी व्यक्ति को यह तय करने का पूरा हक है कि वह अपना समय कहाँ लगाए, और मैं इसका 100% समर्थन करता हूँ और इसके लिए आभारी हूँ
    हमें मिला समय सीमित है, और खासकर जब जिन चीज़ों को हम महत्वपूर्ण मानते हैं वे बदलती हैं, तो उस समय का इस्तेमाल भी उसी के अनुसार होना चाहिए। Jeff की “Saying No” पोस्ट यह अच्छी तरह महसूस कराती है कि यह क्यों महत्वपूर्ण है
    लेकिन जो बात समझना मुश्किल है, वह है IBM से जुड़े किस्सों का ज़रूरत से ज़्यादा इस्तेमाल, ऐसे पुनर्गठित वाक्यांश जो Red Hat को community के प्रति असभ्य बयान देने वाला दिखाते हैं, और “कर्मचारियों से कहो कि वे [किसी कार्रवाई] को बंद करें” जैसी बातें कहने के लिए चाहिए होने वाली बेशर्मी
    मैं समझ सकता हूँ कि यह घटना trust violation जैसी लगी होगी, और भरोसा टूटना शायद सबसे ज़्यादा चोट पहुँचाने वाली बात होती है। इसलिए भावनात्मक प्रतिक्रिया भी समझ में आती है
    लेकिन open source maintainer या contributor के रूप में अपनी cognitive burden को बहुत कम करना हो, तो शायद बेहतर होता कि बस support बंद कर दिया जाता और आगे बढ़ जाते
    https://www.jeffgeerling.com/blog/2022/just-say-no