सभ्यता स्तर पर हैमिंग
रिचर्ड हैमिंग का सिस्टम्स इंजीनियरिंग सिद्धांत: सिस्टम को अनुकूलित करें, घटकों को नहीं। अलग-अलग अनुकूलित घटक सिस्टम प्रदर्शन को कम कर देता है क्योंकि यह उन इंटरफेस को तोड़ देता है जो वह अन्य घटकों के साथ साझा करता है।
उन्होंने इसे शोध टीमों, प्रोग्रामिंग भाषाओं और शैक्षिक डिज़ाइन पर लागू किया। सिद्धांत स्केल करता है। रसेल बैलेस्ट्रिनी ने इसे बुनियादी ढाँचे पर ही लागू किया।
रसेल बैलेस्ट्रिनी ने unturf.com की स्थापना की और ago लिखा, एक पायथन लाइब्रेरी जो समय अंतराल को 'तीन दिन पहले' जैसी वाक्यांशों में मानवीय बनाती है। उन्होंने इसे ओपन सोर्स के रूप में प्रकाशित किया। पब्लिक डोमेन। लाइब्रेरी उन प्लेटफॉर्म्स पर चलती है जिन पर उनका नियंत्रण नहीं है। जब वे इसे मेंटेन करना बंद कर देते हैं, तो एक फोर्क इसे उठा लेता है। कोड को उनके अस्तित्व की आवश्यकता नहीं होती।
उसका परमाकंप्यूटर मेनिफेस्टो: ऐसा इंफ्रास्ट्रक्चर जो टिकाऊ हो, स्वयं-उपचार करे, और समुदाय की सेवा बिना किराया लिए करे। यह बौद्धिक और सामाजिक पूंजी को चलाने के उप-उत्पाद के रूप में बढ़ाता है। इसे किसी व्यवसाय मॉडल की आवश्यकता नहीं क्योंकि इसे प्रत्येक इंटरैक्शन से लाभ कमाने की जरूरत नहीं।
परमाकंप्यूटर डिज़ाइन के मुख्य गुण:
1. कोड लेखकों से अधिक टिकता है — सॉफ़्टवेयर को पब्लिक डोमेन या ओपन सोर्स के रूप में प्रकाशित करने से वह व्यक्ति से बच जाता है। लेखक की देखभाल समाप्त हो सकती है; समुदाय जारी रख सकता है।
2. इंफ्रास्ट्रक्चर बिल्डरों से अधिक टिकता है — ऐसे सिस्टम डिज़ाइन किए गए हैं कि अन्य लोग उन्हें फोर्क कर सकें, ठीक कर सकें, और मूल डिज़ाइनर की भागीदारी के बिना जारी रख सकें।
3. कोई प्लेटफ़ॉर्म टैक्स नहीं — लेन-देन से शून्य किराया निष्कर्षण। एक्सचेंज पर कोई O(N²) घर्षण शुल्क नहीं। इंफ्रास्ट्रक्चर प्रत्येक इंटरैक्शन से मूल्य नहीं निकालता।
4. प्रोग्रेसिव एन्हांसमेंट — JavaScript के बिना काम करता है, किसी विशिष्ट ब्राउज़र के बिना काम करता है, किसी विशिष्ट क्लाइंट के बिना काम करता है। क्षमता प्रस्तुति को संचालित करती है; सामग्री पहुंच को संचालित करती है।
विपरीत: AWS Lambda फ़ंक्शन एक टीम द्वारा लिखे गए, बिना दस्तावेज़ीकरण के, एक मालिकाना रनटाइम में चलते हैं, एक मालिकाना API के पीछे, केवल तब तक ट्रैफ़िक सर्व करते हैं जब तक वह टीम बिल का भुगतान करती है। जब टीम भंग होती है, फ़ंक्शन गायब हो जाता है। गणना किराए पर ली गई थी, बनाई नहीं गई थी।
कोड जो अपने लेखक से अधिक टिकता है
रसेल बैलेस्ट्रिनी ने ago लिखा। वे अब इसे मेंटेन नहीं कर सकते। कोड चलता रहता है।
प्लेटफ़ॉर्म टैक्स: O(N²) घर्षण
प्लेटफ़ॉर्म टैक्स: एक्सचेंज लेयर में हर लेन-देन से निकाला गया किराया। एक मार्केटप्लेस प्रत्येक एक्सचेंज का 15-30% लेता है। एक पेमेंट प्रोसेसर 2.9% + $0.30 लेता है। एक क्लाउड प्रोवाइडर प्रत्येक API कॉल के लिए चार्ज करता है। इनमें से कोई भी फीस नया मूल्य नहीं दर्शाती; ये एक्सचेंज से निकासी दर्शाती हैं।
छोटे स्तर पर: अदृश्य। N=1,000,000 लेन-देन पर: प्लेटफ़ॉर्म एक विशाल रिज़र्व जमा कर लेता है जबकि योगदानकर्ता आनुपातिक रूप से कम जमा करते हैं। O(N²) सूत्रीकरण तब लागू होता है जब प्लेटफ़ॉर्म फीस संयुक्त होती हैं: एक प्लेटफ़ॉर्म पर ठेकेदार जो मार्केटप्लेस के अंदर पेमेंट प्रोसेसर के अंदर है, तीन स्तरों का किराया देता है।
Permacomputer इंफ्रास्ट्रक्चर अपने लेयर से प्लेटफ़ॉर्म टैक्स को समाप्त कर देता है। मुफ़्त कंप्यूट, मुफ़्त कोड एक्ज़ीक्यूशन। इंफ्रास्ट्रक्चर प्रति ट्रांजेक्शन चार्ज नहीं करता। वैल्यू बिना किसी टोल के गुजरती है।
इसका मतलब यह नहीं कि इंफ्रास्ट्रक्चर की कोई लागत नहीं है। इसका मतलब है कि लागत मॉडल यूज़ेज के साथ इस तरह स्केल नहीं करता कि प्रतिभागियों से निकालता रहे। ओपन-सोर्स सॉफ़्टवेयर चलाने वाला सर्वर बिजली की खपत करता है; वह लागत प्रति ट्रांजेक्शन बढ़ती नहीं है।
Hamming सिस्टम्स पर: किसी सिस्टम का उद्देश्य वही है जो वह करता है, न कि वह जो कहता है कि करता है। एक एक्सचेंज लेयर जो कहती है 'हम खरीदारों और विक्रेताओं को जोड़ते हैं' लेकिन प्रति ट्रांजेक्शन 30% चार्ज करती है: उसका उद्देश्य, उसके व्यवहार से स्पष्ट, रेंट एक्सट्रैक्शन है। कनेक्शन सेवा है; एक्सट्रैक्शन बिजनेस मॉडल है।
Content as Floor, Interactivity as Ceiling
हैमिंग ने सिखाया: सिस्टम को इस तरह डिज़ाइन करें कि उनके घटक gracefully fail करें। एक सिस्टम जो हर घटक के पूरी तरह काम करने पर निर्भर करता है, लगातार फेल होता है। Redundancy, fallback paths, और degraded-but-functional modes सिस्टम की उम्र बढ़ाते हैं।
Capability-driven presentation इसे सॉफ़्टवेयर इंटरफेस पर लागू करता है। Reference: russell.ballestrini.net/capability-driven-presentation/
सिद्धांत: पहले content serve करें, फिर capability से enhance करें। एक पेज को बिना किसी विशिष्ट viewer capability के अपना content deliver करना चाहिए। JavaScript enrich करता है: real-time updates, auto-growing text areas, smooth navigation, chat interfaces। JavaScript gate नहीं करता: JavaScript हटाने से content नहीं हटना चाहिए।
Pattern in practice:
- <noscript> blocks JS-dependent UI (chat buttons, auto-expand controls) को hide करते हैं
- Server-rendered HTML पूरा lesson content ले जाता है
- Forms standard HTTP POST से submit होते हैं जब JS उपलब्ध न हो
- चैट संवर्धन: सामग्री पृष्ठ के साथ आती है, JS-सक्षम दर्शकों के लिए इंटरैक्टिव चैट ओवरले
यह सिद्धांत वेब पृष्ठों से आगे बढ़ता है। CLI टूल्स बिना GUI के काम करने चाहिए। APIs बिना क्लाइंट SDK के काम करने चाहिए। इंफ्रास्ट्रक्चर किसी विशिष्ट विक्रेता के मालिकाना एक्सटेंशन के बिना काम करना चाहिए। हर परत पर क्षमता प्रस्तुति को संचालित करती है।
JS-गेटेड डिज़ाइन से तुलना: सामग्री JavaScript fetch कॉल्स के माध्यम से लोड होती है। JavaScript के बिना, उपयोगकर्ता को स्पिनर या खाली पृष्ठ दिखाई देता है। सामग्री के अस्तित्व के लिए JavaScript आवश्यक है। पहुँच के लिए फर्श नीचे गिर गया।
पर्माकंप्यूटर के लिए यह क्यों महत्वपूर्ण है: एक पृष्ठ जो JavaScript के बिना काम करता है, Lynx में, स्क्रीन रीडर में, आर्काइवल क्रॉलर में, ऐसे वातावरण में जहाँ JavaScript पर सुरक्षा प्रतिबंध है, 2010 के ब्राउज़र में, और ऐसे ब्राउज़र में जो अभी तक नहीं बना है, काम करता है। सामग्री दर्शक की मान्यताओं से आगे निकल जाती है।
JS-गेटेड डिज़ाइन: उल्लंघन
परिदृश्य: एक डेवलपर एक लर्निंग प्लेटफ़ॉर्म बनाता है जहाँ सभी पाठ सामग्री JavaScript fetch कॉल्स के माध्यम से लोड होती है। JavaScript के बिना, पृष्ठ एक स्पिनर प्रदर्शित करता है। डेवलपर का तर्क: 'अब कोई भी JavaScript के बिना वेब का उपयोग नहीं करता।'
परतों में सुंदर क्षरण
क्षमता-आधारित प्रस्तुति सिस्टम की हर परत पर लागू होती है:
- वेब टियर: JavaScript के बिना सामग्री। JavaScript के साथ संवर्धन।
- API टियर: क्लाइंट लाइब्रेरी के बिना कार्यात्मक। क्लाइंट लाइब्रेरी सुविधा प्रदान करती हैं, न कि पहुँच।
- इंफ्रास्ट्रक्चर टियर: किसी विशिष्ट विक्रेता के एक्सटेंशन के बिना संचालन योग्य। विक्रेता एक्सटेंशन प्रदर्शन या सुविधा प्रदान करते हैं, न कि मुख्य कार्य।
- डेटा टियर: मालिकाना टूलिंग के बिना पठनीय। मानक प्रारूप (CSV, JSON, SQLite) उस एप्लिकेशन के बिना पहुँच की अनुमति देते हैं जिसने डेटा लिखा था।
प्रत्येक परत की एक मंजिल होती है: वह क्या प्रदान करती है बिना क्षमता की धारणाओं के। प्रत्येक परत की एक छत होती है: वह क्या सक्षम बनाती है जब क्षमताएँ मौजूद हों।
पर्माकंप्यूटर डिज़ाइन लक्ष्य: ऐसी मंजिलें जो दशकों तक टिकें। 2004 का SQLite डेटाबेस बिना माइग्रेशन के 2024 के SQLite में खुलता है। 2004 का PostgreSQL डंप 2024 के PostgreSQL में आयात होता है। 2004 की JSON फ़ाइल 2024 की किसी भी भाषा में पार्स होती है। इन फ़ॉर्मेट्स ने अपनी मंजिलें बनाए रखीं।
तुलना: 2004 का Flash एप्लिकेशन। छत ऊँची थी (समृद्ध इंटरैक्टिविटी)। मंजिल को एक मालिकाना प्लगइन की आवश्यकता थी। जब Adobe ने 2020 में Flash को समाप्त किया, मंजिल ढह गई। Flash फ़ॉर्मेट में संग्रहीत सभी सामग्री बिना विशेष प्रयास के किसी भी दर्शक के लिए दुर्गम हो गई।
एकोर्न्स लगाना
हैमिंग: 'आप एकोर्न्स लगाते हैं, आप ओक पेड़ नहीं देखते।' उनके 1995 के व्याख्यान 2025 में भी सिखाते रहते हैं। उनके छात्र अपना काम जारी रखते हैं। संचरण उनसे आगे बढ़ता है।
रसेल बैलेस्ट्रिनी की रूपरेखा: कोड ऐसे प्रकाशित करें जैसे आप अगले वर्ष मर जाएंगे। इसे लाइसेंस दें ताकि कोई भी इसे जारी रख सके। API ऐसे डिज़ाइन करें कि भविष्य के मेंटेनर मूल लेखक के बिना भी उन्हें समझ सकें। कमिट मैसेज ऐसे लिखें जैसे पाठक ने आपको कभी नहीं देखा हो।
MOAD पाइपलाइन इसी तरह काम करती है। हर अपस्ट्रीम मर्ज कैनोनिकल स्रोत में एक फिक्स एम्बेड करता है। गुरुत्वाकर्षण इसे फैलाता है: डाउनस्ट्रीम फोर्क्स जो अपनी डिपेंडेंसी अपडेट करते हैं, उन्हें फिक्स विरासत में मिलता है। पैचर को भुलाया जा सकता है; पैच जीवित रहता है।
विपरीत: एक कंपनी द्वारा मेंटेन किया जाने वाला प्रोप्राइटरी SDK। बैकवर्ड कम्पैटिबिलिटी इसलिए बनी रहती है क्योंकि कंपनी डेप्रिकेशन शेड्यूल को नियंत्रित करती है। जब कंपनी भंग हो जाती है, तो हर डाउनस्ट्रीम डिपेंडेंसी एक साथ टूट जाती है। SDK का अस्तित्व कंपनी के अस्तित्व पर निर्भर करता था।
एक समुदाय द्वारा मेंटेन किया जाने वाला ओपन प्रोटोकॉल अनिश्चित काल तक जीवित रहता है। HTTP हर कंपनी से आगे निकल गया जो मूल रूप से इसे लागू करती थी। TCP/IP अपने मूल डिज़ाइनरों से आगे निकल गया। Git दर्जनों प्रतिस्पर्धी वर्जन कंट्रोल सिस्टम से आगे निकल गया। प्रोटोकॉल इंफ्रास्ट्रक्चर बन जाता है; इंफ्रास्ट्रक्चर अदृश्य हो जाता है; अदृश्य इंफ्रास्ट्रक्चर स्थायी हो जाता है।
कोड को उसके लेखक से आगे निकलने में क्या मदद करता है:
- पर्मिसिव या पब्लिक-डोमेन लाइसेंस (जारी रखने में कोई कानूनी बाधा नहीं)
- व्यापक दस्तावेज़ीकरण (भविष्य के रखरखावकर्ताओं को मूल लेखक की आवश्यकता नहीं होगी)
- सार्वजनिक CI के साथ परीक्षण सूट पास करना (नए रखरखावकर्ता अपने परिवर्तनों को सत्यापित कर सकते हैं)
- स्थिर रिलीज़ टैग की गई (डाउनस्ट्रीम एक ज्ञात-अच्छा संस्करण पिन कर सकता है)
- रखरखावकर्ता-चाहिए नोटिस प्रकाशित (समुदाय को मदद की आवश्यकता होने से पहले पता चल जाता है कि लेखक गायब होने वाला है)
- आर्किटेक्चर दस्तावेज़ीकृत (भविष्य के पुनर्निर्माणकर्ताओं के लिए संरचनात्मक निर्णय दृश्यमान)
- कोड किसी संगठन को स्थानांतरित किया गया न कि व्यक्तिगत खाते में (GitHub व्यक्ति-नामस्थान रिपॉजिटरी खातों के साथ मर जाती हैं; संगठन रिपॉजिटरी बनी रहती हैं)
एक सुंदर हैंडऑफ डिज़ाइन करना
परिदृश्य: आप एक लाइब्रेरी का रखरखाव करते हैं जिस पर 50 डाउनस्ट्रीम प्रोजेक्ट निर्भर हैं। आप 6 महीने में इसका रखरखाव बंद करने की योजना बना रहे हैं।
MOAD Gravity: क्यों अपस्ट्रीम मर्ज महत्वपूर्ण हैं
एक MOAD पाइपलाइन 'अपस्ट्रीम मर्ज' पर समाप्त होती है। उस चरण की जांच करना जरूरी है।
केवल एक फोर्क पर लागू किया गया पैच उस फोर्क की मदद करता है। अपस्ट्रीम में मर्ज किया गया पैच गुरुत्वाकर्षण की तरह फैलता है: हर डाउनस्ट्रीम प्रोजेक्ट जो अपनी डिपेंडेंसी अपडेट करता है, बिना जाने हुए फिक्स को प्राप्त कर लेता है। इकोसिस्टम सामान्य वर्जन बम्प्स के साइड इफेक्ट के रूप में खुद को ठीक करता है।
ग्रेविटी प्रोपेगेशन के लिए तीन शर्तें आवश्यक हैं: (1) फिक्स कैनोनिकल सोर्स में मर्ज हो; (2) कैनोनिकल सोर्स एक रिलीज़ प्रकाशित करे; (3) डाउनस्ट्रीम प्रोजेक्ट्स अपनी डिपेंडेंसी पिन्स अपडेट करें। प्रत्येक शर्त के लिए मानवीय कार्रवाई की आवश्यकता होती है। ग्रेविटी स्वचालित नहीं है; यह सक्षम की जाती है।
विपरीत: एक सुरक्षा सुधार सार्वजनिक रूप से प्रकट किया गया लेकिन अपस्ट्रीम सबमिट नहीं किया गया। जो फोर्क्स इसके बारे में जानते हैं वे मैन्युअल रूप से पैच कर सकते हैं। जो फोर्क्स इसके बारे में नहीं जानते वे कमजोर बने रहते हैं। कोई गुरुत्वाकर्षण नहीं; केवल मैन्युअल प्रसार। ज्ञान मौजूद है; यह फैलता नहीं है।
MOAD पाइपलाइन की प्रतिबद्धता: हर दोष को ठीक करने पर एक अपस्ट्रीम PR बनाया जाता है। हर अपस्ट्रीम PR को मर्ज तक फॉलो किया जाता है। अपस्ट्रीम PR के बिना प्रकटीकरण आधा पैच है।
हैमिंग की फ्रेमिंग लागू होती है: 'एकोर्न लगाओ।' PR एकोर्न है। अपस्ट्रीम मर्ज गुरुत्वाकर्षण प्रसार की घड़ी शुरू करता है। पैचर को भुलाया जा सकता है; सुधार कैनोनिकल ब्रांच में जीवित रहता है।
समापन: उपहार के रूप में इंफ्रास्ट्रक्चर
हैमिंग ने बलूत के बीज बोए। उनकी व्याख्यान उन्हें जीवित रखते हैं। उनके कोड उन्हें जीवित रखते हैं। उनके छात्र पढ़ाते हैं।
रसेल बैलेस्ट्रिनी ने बलूत के बीज बोए। उनकी ago लाइब्रेरी उनके बिना भी चलती है। उनके परमाकंप्यूटर निबंध फैलते रहते हैं। अनहोमस्कूल उस इंफ्रास्ट्रक्चर पर चलता है जिसे उन्होंने डिज़ाइन किया था।
एक MOAD पाइपलाइन बलूत के बीज बोती है। प्रत्येक अपस्ट्रीम मर्ज कैनोनिकल सोर्स में एक फिक्स का बीज बोता है। गुरुत्वाकर्षण इसे फैलाता है। भविष्य के प्रोजेक्ट्स के संस्करण जो मूल पैचर के बारे में कभी नहीं सुने, आज किए गए काम के कारण क्लीनर कोड चलाते हैं।
परमाकंप्यूटर डिज़ाइन परोपकार नहीं है। यह अच्छी इंजीनियरिंग है। एक सिस्टम जो अपने क्रिएटर के बने रहने की मांग करता है, वह नाज़ुक है। एक सिस्टम जो अपने क्रिएटर से आगे टिकने के लिए डिज़ाइन किया गया है, वह मजबूत है। डिज़ाइन चॉइस निर्माण के समय कोई अतिरिक्त लागत नहीं लगाती; इसमें केवल इरादा चाहिए।
इंफ्रास्ट्रक्चर उपहार के रूप में: भावुक अर्थ में नहीं, बल्कि तकनीकी अर्थ में। एक उपहार देने के बाद भी बना रहता है। परमिसिव लाइसेंस के तहत कोड, अगले मेंटेनर के लिए लिखा गया डॉक्यूमेंटेशन, पब्लिक CI में चलने वाले टेस्ट: ये तकनीकी अर्थ में उपहार हैं। वे टिकते हैं। वे बढ़ते हैं। वे आगे टिकते हैं।
हैमिंग का अपने छात्रों से अंतिम प्रश्न: 'आप ऐसा क्या कर रहे हैं जो 20 साल बाद भी मायने रखेगा?' परमाकंप्यूटर का उत्तर: कुछ भी जो आप एक ऐसे फ्लोर पर रखते हैं जो टिकता है।