- Debian की अनोखी practices उन विकल्पों से निकली हैं जिन्हें 30 साल पुराने बड़े general-purpose operating system ने quality, security और free software सिद्धांतों को लंबे समय तक बनाए रखने के लिए अपनाया
- किसी खास use-case वाली distribution होने के बजाय, यह ज़्यादातर लोगों और उद्देश्यों के लिए उपयुक्त general-purpose distribution बनने का लक्ष्य रखता है; package शामिल करना है या नहीं, इसके मुख्य मानदंड free software होना और maintenance quality हैं
- Constitution, Social Contract और DFSG ऐसे mechanisms हैं जो शुरुआती ढीले-ढाले संचालन की सीमाएँ सामने आने के बाद बने; ये democratic decision-making और सीमित leader powers को institutionalize करते हैं
- self-contained builds और bundled libraries से बचना एक maintenance strategy है, ताकि external repositories या duplicate dependencies पर निर्भर हुए बिना urgent security fixes, rebuilds और नए architectures पर porting संभव हो सके
- membership vetting, release codenames और बदलाव की धीमी गति ऐसे तरीके हैं जिनसे हजारों packages और करोड़ों installations वाले project में trust, mirroring costs और consensus costs को manage किया जाता है
Debian किस तरह का operating system बनना चाहता है
- Debian का लक्ष्य high-quality, secure और general-purpose operating system होना है, जो सक्रिय रूप से इस्तेमाल होने वाले अधिकतर computers पर चल सके और केवल free व open source software से बना हो
- general-purpose operating system का लक्ष्य यह है कि Debian ज़्यादातर लोगों के लिए, ज़्यादातर उद्देश्यों में उपयुक्त होना चाहिए
- यह हर स्थिति के लिए सही नहीं हो सकता, लेकिन लक्ष्य के रूप में अपनाने योग्य दिशा है
- इससे desktop, server, gaming या scientific research जैसे किसी खास उद्देश्य पर केंद्रित distributions से अलग decisions निकलते हैं
- किसी software को package करना है या नहीं, यह उसके उपयोग से अधिक इन मानदंडों पर निर्भर करता है
- क्या software free software है
- क्या Debian उसे high-quality package के रूप में maintain कर सकता है
Constitution और governance
- Debian स्पष्ट रूप से democratic open source organization के करीब है
- decision-making process अच्छी तरह defined है
- हर साल Debian Project Leader चुना जाता है
- project leader की powers सख्ती से सीमित हैं, और आम तौर पर leadership से जुड़ी कई powers साफ तौर पर दूसरे लोगों को delegate की जाती हैं
- शुरुआती Debian Project Leaders, खुद पद छोड़ने तक, व्यवहार में लगभग पूर्ण अधिकारों वाले dictators जैसे थे
- एक project leader ने सीमा पार की, विरोध के बाद पद छोड़ा, और उसी के परिणामस्वरूप democracy लाई गई
- Debian अपने आधिकारिक Constitution में project rules define करता है
- मौजूदा rules system Debian के शुरुआती इतिहास में कम rules और कम bureaucracy के ठीक से काम न करने के अनुभव से निकला है
Social Contract और Debian Free Software Guidelines
- 1990s के मध्य में “open source” शब्द introduce होने से पहले की बात थी, और “free software” को Free Software Foundation ने define किया था, लेकिन उसकी interpretation की गुंजाइश काफी थी
- Debian ने अधिक स्पष्ट rules चाहीं, इसलिए Debian Free Software Guidelines(DFSG) बनाईं और उन्हें Social Contract का हिस्सा बनाया
- Social Contract वह foundational document है जिसमें Debian खुद से और दुनिया से यह वादा करता है कि वह क्या है और क्या करता है
- DFSG उसका एक हिस्सा है
- Debian Constitution जानबूझकर Social Contract को बदलना कठिन बनाता है
- अधिक detailed rules यह स्पष्ट करते हैं कि Debian क्या accept करेगा, और संबंधित discussions को सरल बनाते हैं
- DFSG बाद में Open Source Definition का आधार बना
self-contained build का सिद्धांत
- Debian self-contained सिद्धांत पर जोर देता है
- Debian द्वारा package की गई हर चीज Debian के अंदर मौजूद dependencies का ही उपयोग करके build होनी चाहिए
- Debian के अंदर की हर चीज Debian को खुद build करनी चाहिए
- यह सिद्धांत काफी अतिरिक्त काम पैदा कर सकता है
- आज के programming language tools अक्सर यह मानकर चलते हैं कि build time पर online repositories से dependencies download की जाएँगी
- Debian में ऐसा तरीका allowed नहीं है
- मुख्य वजह यह है कि external dependencies बाद में गायब हो सकती हैं
- Debian third-party package repositories को control नहीं करता
- अगर कोई package या पूरा repository गायब हो जाए, तो Debian उस package को दोबारा build नहीं कर पाएगा
- नया compiler upgrade, security issue fix, नए architecture पर porting, और bug fixes शामिल करने के लिए rebuild जरूरी होता है
- self-contained न होने पर urgent security fix के समय दसियों हजार packages और उनकी dependencies सभी उपलब्ध होनी चाहिए; इसलिए Debian सभी dependencies को package करने का रास्ता चुनता है
bundled libraries से बचने की वजह
- Debian package किए जाने वाले software में शामिल library copies या अन्य dependency copies के उपयोग से बचता है
- कई upstream projects dependencies को साथ में bundle या vendor करना आसान मानते हैं
- Debian के लिए इसका मतलब हो सकता है कि किसी popular library की कई copies बन जाएँ
- अगर उस library में security issue या गंभीर problem आती है, तो सभी copies ढूँढकर ठीक करनी पड़ेंगी
- urgent security issue में यह काम कीमती समय बर्बाद करता है
- zlib के मामले में Debian ने archive के अंदर bundled zlib की दर्जनों copies पाईं, और Debian packages को केवल Debian में packaged zlib version इस्तेमाल करवाने में काफी मेहनत की
- इसलिए Debian emergency आने से पहले ही packaging stage में काम कर लेता है, ताकि Debian के अंदर packages Debian में packaged library versions का उपयोग करें
- upstream developers कई बार सिर्फ अपने द्वारा verified bundled versions से ही deal करना चाहते हैं, इसलिए यह तरीका कभी-कभी Debian के साथ friction पैदा करता है
membership vetting process
- operating system के रूप में Debian बड़ा, जटिल और व्यापक रूप से इस्तेमाल किया जाने वाला project है, इसलिए उसे अपने members पर भरोसा करना पड़ता है
- खासकर नए packages upload करने वाले लोगों पर trust महत्वपूर्ण है
- 1990s में Linux की technical limitations के कारण सभी Debian packages को installation process के दौरान पूरा root access मिलता था
- हर Debian developer संभावित रूप से Debian चलाने वाली किसी भी machine पर root user बन सकता है
- Debian करोड़ों machines पर चलता है, इसलिए यह बहुत बड़ी power है
- नए members को कई तरीकों से verify किया जाता है
- आदर्श रूप से, उन्हें Debian development community में इतना लंबे समय तक शामिल रहना चाहिए कि दूसरे लोग उन्हें जानने लगें
- community के भीतर trust बनाना पड़ता है
- Debian में शामिल होना चाहने वालों, खासकर छोटे open source projects के आदी लोगों के लिए यह process काफी frustrating हो सकता है
release codenames
- Debian हर major release को codename देता है
- यह practice मूल रूप से Debian package archive की mirroring cost कम करने के लिए शुरू हुई थी
- 1990s के मध्य में Debian 1.0 release तैयार करते समय codenames का उपयोग नहीं किया गया था और directories version names से बनाई गई थीं
- नए release के development में समय लगता है, इसलिए “1.0” directory पहले से बना दी गई
- एक CD-ROM publisher ने Debian 1.0 पूरा होने से पहले ही “1.0” label वाली disks का जल्दी mass production कर दिया
- परिणामस्वरूप, Debian 1.0 CD-ROM पाने वाले लोगों को असली 1.0 नहीं मिला
- सरल समाधान यह था कि “1.0-not-released” जैसी directory में तैयारी की जाए और release पूरा होने के बाद उसका नाम “1.0” कर दिया जाए
- लेकिन directory name बदलने पर सभी mirrors को release फिर से download करना पड़ता, और उस समय Debian के scale पर यह cost बड़ी थी
- उस समय scale “सैकड़ों packages” और “दर्जनों MB” के स्तर का था
- बाद में Debian archive में pool structure जोड़ा गया
- सभी releases की files एक ही directory tree में होती हैं, और metadata files यह तय करती हैं कि कौन-सी files किस release से संबंधित हैं
- यह structure mirroring को आसान बनाता है
- आज codenames छोड़कर सिर्फ versions इस्तेमाल करना संभव हो सकता है, लेकिन Debian इसमें रुचि लेगा या नहीं, यह पता नहीं
Debian धीरे-धीरे क्यों बदलता है
- Debian बहुत बड़ा project है, और बड़े projects धीरे-धीरे बदलते हैं
- कई packages को प्रभावित करने वाले changes पर सैकड़ों volunteers को काम करना पड़ सकता है, इसलिए वे जल्दी आगे नहीं बढ़ पाते
- कुछ काम कम लोग संभाल सकते हैं, और Debian में इसे संभव बनाने वाली प्रक्रियाएँ हैं
- उदाहरण के लिए GNU C compiler का नया version upload होने पर, दूसरे packages में जरूरी fixes ढूँढने का काम आम तौर पर कुछ ही लोग कर सकते हैं
- बदलाव में समय लगने की वजह consensus building की जरूरत भी है
- consensus के लिए व्यापक discussion चाहिए
- ऐसी discussions में समय लगता है, और उन्हें बहुत कम मामलों में ही छोटा किया जा सकता है
- Debian developers technical decisions में conservative होते हैं
- वे अक्सर ऐसे solutions पसंद करते हैं जिनके लिए बड़े पैमाने पर changes की जरूरत न हो
1 टिप्पणियां
Hacker News की रायें
Self-contained और बंडल की हुई लाइब्रेरी न होना ऐसे अहम कॉन्सेप्ट हैं जिन्हें ecosystem के एक हिस्से ने बहुत झंझटिला समझकर नज़रअंदाज़ कर दिया
उससे पैदा हुई समस्याओं को दोबारा झेलने के बाद ही लोगों ने “software supply chain” जैसे शब्द दिए, और Debian शुरू से ही इन समस्याओं से बचने के तरीके से काम करता आया है, इसलिए उसे वही दर्द कम झेलना पड़ा
कई distributions और operating systems में software distribute करना हो तो dependency bundling तर्कसंगत है, और distribution maintain करने वाले के नज़रिए से shared libraries साफ़ तौर पर बेहतर हैं, क्योंकि security patch सिर्फ़ एक बार लगाना पड़ता है
operating system स्तर पर Nix और Silverblue, application स्तर पर Snaps और Flatpak जैसे ट्रेंड आ रहे हैं; समाधान नहीं पता, लेकिन लगता है Debian को भी जल्द ही कुछ करना होगा
दूसरी version इस्तेमाल करनी हो तो सावधानी से test करना और मिले हुए bugs ठीक करना पड़ता है; पता नहीं Debian के पास इसके लिए संसाधन हैं या नहीं, और अंत में वह अप्रमाणित library combinations इस्तेमाल करके बस उम्मीद करता है कि सब ठीक चलेगा, लेकिन ऐसा होता नहीं लगता
बहुत पहले से linux-firmware repository से ली गई public firmware को source से build नहीं किया जाता था, सिर्फ़ binary ही distribute होती थी, और archive में भी ऐसे और उदाहरण होंगे
Debian हर tarball से generated files को systematic तरीके से हटाकर दोबारा generate भी नहीं करता; खासकर AI/ML की तरफ़ तो training data भी शायद न मिल पाए और training cost उठाना भी मुश्किल होगा
https://wiki.debian.org/EmbeddedCopies
कुछ open source software organizations सिर्फ़ थोड़ी-बहुत प्रभावशाली नहीं हैं, बल्कि इतनी अद्भुत हैं कि दिखाती हैं कि लोगों के collaboration का तरीका पारंपरिक corporate model से कहीं बेहतर हो सकता है
मैं Debian बहुत लंबे समय से इस्तेमाल कर रहा हूं, लेकिन संगठन के बारे में ज़्यादा नहीं जानता था, और यह लेख अच्छा introduction था
IETF ने भी लगभग internet बनाया है, फिर भी उसके members नहीं हैं और वह बस चलता रहता है; हैरानी है कि ऐसे organizations ज़्यादा जाने-पहचाने नहीं हैं
corporate दुनिया ने internet के काम करने के तरीके पर कब्ज़ा करने के लिए IETF से जो Protocol Wars में मुकाबला किया था, वह भी दिलचस्प है: https://en.wikipedia.org/wiki/Protocol_Wars
एक समय था जब OSI हर महीने TCP जैसे internet के हिस्सों को X.protocols से बदलने की projects घोषित करता था, लेकिन बचकर फलने-फूलने वाला लगभग X.509 ही रहा
सोचता हूं कि क्या ऐसे democratic collaboration organizations सच में traditional corporate model से बहुत बेहतर हैं
economic scale से देखें तो IETF या Debian की income companies के सामने कुछ नहीं, लेकिन contributor और creator के नज़रिए से सवाल उठता है, “फायदा किसे होता है?”, और contributors बस किसी तरह टिके रहते हैं
IETF या Debian वाला model corporate model से मुकाबला कर सकता है या नहीं, यह आज़माने लायक लगता है, और Protocol Wars में यह सचमुच एक बार कामयाब हुआ था
IETF working groups में interoperability के लिए collaborate करने वाले corporate vendor engineers बहुत होते हैं, जबकि ISO पारंपरिक top-down, government-led organization के ज़्यादा करीब है
मैंने लगभग 13 साल Ubuntu इस्तेमाल करने के बाद इस साल Debian पर switch किया और यह मुझे काफ़ी पसंद आया
पहले मुझे लगता था कि global update वाले packaging model में यह समझना मुश्किल होता है कि क्या हो रहा है, और कभी-कभी version conflicts भी आ जाते हैं, इसलिए तकनीकी रूप से यह सबसे मजबूत तरीका नहीं है
लेकिन समय के साथ मैंने Debian की stability और project की नेक नीयत को ज़्यादा सराहना शुरू किया
कभी-कभी technical superiority से ज़्यादा project का purpose और goals अहम होते हैं
install के बाद daemons का automatically start होना जैसे technical choices से शिकायत है, लेकिन packages और upgrades में कुल मिलाकर मिलने वाली consistency का फायदा बड़ा है
Apt भी वाकई शानदार package manager है
default हालत में भी तेज़ है, और system को stable रखते हुए सिर्फ़ Nginx को backports से नई version में इस्तेमाल करने जैसे काफ़ी tricky scenarios भी support करता है
यह एहसास अच्छा है कि जिन एक-दो packages की परवाह है उनमें नई features मिल जाएं, और बाकी सब stable और boring बना रहे
मुख्य वजह यह है कि यह boring और पुरानी, लेकिन ठीक से काम करने वाली technology इस्तेमाल करता है, और अब netplan, snapd, systemd-resolver नहीं देखने पड़ते
Sid से package लेने या libc6 upgrade जैसी मज़ेदार चीज़ें न कर रहे हों, तो अगर सब कुछ apt से install किया है, version conflicts आम तौर पर दिखने नहीं चाहिए
LIW ने एक बड़ा हिस्सा छोड़ दिया: Debian एक volunteer organization है, इसलिए किसी volunteer को वह काम करने के लिए कोई मजबूर नहीं कर सकता जो वह नहीं करना चाहता
बिना ज़बरदस्ती के लोग loosely rotating democracy structure बनाकर decisions लेते हैं, और सावधानी से resources इस्तेमाल करने से आने वाली self-sufficiency organization का core लगती है
मेरे लिए उस conflict ने “Debian क्या है” की अवधारणा को स्थायी रूप से बदल दिया, और वह अच्छा था या बुरा, यह इस पर निर्भर करता है कि आप किसकी बात सुनते हैं
ऐसे organizations में भी अगर आप वैसा नहीं करते जैसा दूसरे लोग कहते हैं, तो जाहिर है आपको दरवाज़े से बाहर जाना पड़ता है
कभी-कभी कल्पना करता हूँ कि मेरे पास इतना पैसा हो कि पैसों की बिल्कुल चिंता न रहे
तब हमेशा योजना बनाता हूँ कि किन open source projects को दान दूँगा, और Debian हमेशा शुरुआती कुछ उम्मीदवारों में रहता है
अब बस पैसे की कमी है, हालांकि इस बीच भी मैं Debian को दान दे रहा हूँ
वह कहीं ज्यादा मजेदार होगा
Debian शानदार हो सकता है, लेकिन उसमें driver support की समस्या है, और लगता है कि वह इसे बस अनिच्छा से ही स्वीकार करता है
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“हम मानते हैं कि कुछ users को ऐसे programs की जरूरत होती है जो Debian Free Software Guidelines के अनुरूप नहीं हैं। ऐसे software के लिए हमने FTP archive में contrib और non-free sections बनाए हैं।”
1–2 साल पहले मैंने कुछ machines पर Debian चलाया था, लेकिन WiFi update आने के बाद वह ठप हो गया। rollback वगैरह देखने के बाद मैंने बस Ubuntu, असल में Kubuntu, पर switch कर लिया और वह ठीक चला, कोई समस्या नहीं आई
Debian 12 ने तो एक dedicated non-free-firmware repository भी बनाया, ताकि free software purists hardware इस्तेमाल करने के लिए कम से कम non-free drivers पर समझौता कर सकें
अगर system पहले से installed है, तो non-free repository enable करके linux-firmware, या अपने hardware के हिसाब से ज्यादा specific firmware-* package install करने से समस्या हल हो जानी चाहिए
शुरुआती release के दिनों में Purdue में Ian Murdock के साथ काम किया था
वह system administrator और developer थे, और मैं library web designer था
वह GNU/Linux तरीके और “बोलने की आजादी के रूप में freedom” वाले software में सचमुच विश्वास रखते थे
शुरुआती प्रेरणा packaging और package management की कठिनाइयों से आई थी, और शायद यही उनका सबसे बड़ा योगदान था
Network-of-Workstations, यानी NOW नाम के P2P infrastructure जैसे विचार को लेकर भी वे उत्साहित थे, लेकिन वह ठीक से जड़ नहीं पकड़ पाया
जिसे उन्होंने जिम्मा सौंपा, Bruce Perens, वही लेख में बताए गए authoritarian leader हैं
मुझे वह पसंद हैं, और उनका management style Linus Torvalds जैसे old guard वाला है; बहुत सारे volunteers वाले बड़े और जटिल projects में यह style काम करता है
पुराने Linux और Debian वाले दिन सच में मजेदार थे, और मैं दूसरों जितना गहराई से उसमें नहीं डूबा था, फिर भी वह समय याद आता है
आजकल पैसे की गंध सूँघने वाले लोग बहुत ज्यादा आ गए हैं, खैर ऐसा ही होता है
Ian का manifesto सब समझा देता है: https://www.debian.org/doc/manuals/project-history/manifesto...
मैंने यह कहानी कभी नहीं सुनी और Google भी मददगार नहीं है
उनके पद छोड़ने के बाद से मृत्यु तक का उनका सफर काफी अस्थिर लगता है
वह मुझसे भी पुरानी है
Debian Toyota जैसा है
भरोसेमंद, लेकिन उबाऊ, और ऊपर से volunteers द्वारा बनाया गया
Debian policy की वजह से कभी-कभी असली version के बजाय काफी सीमित RetroArch version दिया जाता है
RetroArch में “Core Updater” नाम का अपना package management feature है, जो emulators को library files के रूप में download और install करता है, लेकिन Debian इसे इसलिए प्रतिबंधित करता है क्योंकि यह पूरे package manager system को bypass करता है
हालांकि Debian source package की dependencies install करने के बाद अगर original source code build किया जाए, तो full functionality वाला RetroArch खुद build किया जा सकता है
Kodi और RetroArch चलाने की कोशिश में यह मुश्किल से सीखा, लेकिन इसके अलावा यह शानदार operating system है
निजी तौर पर Debian के सिद्धांतों और stability की वजह से मुझे यह पसंद है और मैं इसका इस्तेमाल करता हूँ
मैंने दूसरे distributions के users या कुछ upstream projects से यह शिकायत सुनी है कि Debian packages को “modify” करता है
क्या सच में ऐसा है? अगर हाँ, तो इसके पीछे ज़रूर कोई अच्छा कारण होगा—मैं इसकी व्याख्या सुनना चाहता हूँ
पहला, ऐसे patches जो software को Debian के चाहने वाले तरीके से काम करवाते हैं: configuration को /etc/ में रखना, runtime में अतिरिक्त downloads न करना, और bundled libraries की जगह system libraries का इस्तेमाल करना
दूसरा, security backports हैं
Debian release के समय features को freeze कर देता है और केवल security updates देता है, लेकिन आजकल कई software security fixes को भी नए features के साथ नई release में ही bundle करते हैं
जब ये दोनों तरह मिल जाते हैं, तो Debian के 1.2 और “असली” 1.2 के बीच अंतर बड़ा हो जाता है, और bug reports संभालना मुश्किल हो जाता है
उदाहरण के लिए, 1.2-Debian की bug report मिलती है, लेकिन upstream project updated libraries के bundle के साथ केवल “असली” 1.4 को support करता है
तीसरा तरीका आजकल काफी हद तक कम हो गया है: जब Debian को लगता है कि वह software को बेहतर बना सकता है, तो वह patch करता है
इसकी वजह से SSH keys से randomness हट जाने जैसी समस्याएँ भी हुई हैं: https://github.com/g0tmi1k/debian-ssh
एक Chrome जैसा incremental version तरीका है, जहाँ bug-fix releases लगभग अलग से नहीं होतीं और bug fixes नए versions में शामिल होते हैं
दूसरा major-version-केंद्रित तरीका है: semantic versioning की तरह version 1 और 2 होते हैं, और version 2 के बाद भी version 1 में केवल bug fixes लगाकर 1.1 निकलता है
Debian मूल रूप से केवल दूसरे तरीके में ही ठीक से काम करता है
क्योंकि यह API stability बनाए रखता है, इसलिए पहले तरीके से विकसित software के साथ यह मेल नहीं खाता
इससे बचने के लिए Debian version 3 की “fixes” को version 1 में backport करके अपना 1.debian-2 बनाता है
समस्या यह है कि अब upstream project को ऐसे behavior पर bugs मिलते हैं जिसे उसने कभी release ही नहीं किया
Debian को ऐसा करने की आज़ादी है, लेकिन upstream project को भी Debian द्वारा डाले गए अतिरिक्त workload से शिकायत करने की आज़ादी है
ज़रूरत पड़ने पर वह उन upstream projects को patch करता है जो इन expectations से मेल नहीं खाते, और ठीक ऐसा कर पाना ही free software का मूल है
https://www.debian.org/security/2008/dsa-1571 देखें