क्या किसी को पता है कि emacs का मतलब क्या है? मतलब तो है, लेकिन ऐसे acronym वाले नाम एक नज़र में समझ भी नहीं आते, और आखिरकार यह एक नाम ही है… और अब सिर्फ़ फ़ंक्शन के आधार पर नाम रखने के लिए प्रोजेक्ट्स की संख्या भी बहुत ज़्यादा हो चुकी है।
AI को अधिकार देना आखिरकार इंसान ही करते हैं, लेकिन व्यावहारिक रूप से मुझे लगता है कि AI को कम से कम अभी से भी अधिक बड़े अधिकार और स्वायत्तता मिलने की संभावना काफी अधिक है.
अभी के रुझान को देखें तो AI को इंसानों की जगह कुछ काम सौंपने का दायरा धीरे-धीरे बढ़ता जा रहा है. रिपोर्ट लिखने या vibe coding ही नहीं, बल्कि web browser या यहाँ तक कि robots के ज़रिये chat interface के बाहर की दुनिया पर भी असर डालने लायक बनाने की दिशा में रुझान है.
अगर ऐसा है, तो management अंततः चाहेगा कि किसी खास काम या क्षेत्र में AI इंसानों को पूरी तरह replace कर दे, और यदि यह संभव हो जाता है, तो कम से कम उस दायरे में AI के पास इंसान के बराबर अधिकार और स्वायत्तता होगी.
इसलिए मुझे लगता है कि हमें यह मानकर चलना चाहिए कि भविष्य में कभी AI को इंसान-स्तर के अधिकार मिलने की संभावना भी काफी अधिक है.
ऐसी स्थिति में, जब इतना अधिक अधिकार और स्वायत्तता दी जाएगी, तब AI कैसे व्यवहार करता है, यह महत्वपूर्ण होना ही है.
इस हिस्से को संरचनात्मक रूप से कैसे संभालना बेहतर होगा, इस बारे में GPT series की प्रतिक्रियाओं में अच्छी तरह व्यवस्थित किया गया है. वहाँ कहा गया है कि explicit scope definition, authority separation, कई स्तरों पर prior/post supervision, और इंसानों के पास AI में हस्तक्षेप करने के कई साधन होने चाहिए. जहाँ physical intervention संभव हो, वहाँ तो शुरू से ही AI को पूर्ण autonomy देना अनुचित है. लेकिन उस स्थिति में भी, human-in-the-loop की व्यवस्था भी कभी न कभी कमजोर पड़ सकती है.
संदर्भ के लिए, मैं काम के दौरान मुख्य रूप से 3 हिस्सों में AI का उपयोग करता हूँ: document या email writing, existing code और current issue analysis, और issue के अनुसार code generation तथा modification.
इसमें document या email जैसी चीज़ों के मामले में मैं बस output को खुद पढ़कर वैसा ही इस्तेमाल कर लेता हूँ, या थोड़ा-बहुत ठीक करके लिख देता हूँ. लेकिन जहाँ code generation या modification शामिल हो, वहाँ मैं कहीं ज़्यादा conservative तरीके से इस्तेमाल करता हूँ. सिर्फ़ मोटे तौर पर "इसे थोड़ा ठीक कर दो" कह देने पर AI मेरे निर्देश को अस्पष्ट ढंग से समझ लेता है, या कभी-कभी उन हिस्सों को भी अपनी तरफ़ से छेड़ देता है जिनका मैंने ज़िक्र तक नहीं किया था.
इसलिए code modification से पहले मैं STICC के अनुसार spec document हमेशा पहले पेश करने और explicit approval लेने की बात global prompt में तय करके रखी है, और वास्तविक modification का काम केवल spec में लिखी बातों तक ही सीमित रखता हूँ. modification के बाद diff भी मैं पूरा खुद जाँचता हूँ. और build जैसे commands चलाने के लिए भी या तो हमेशा मेरी approval ली जाती है, या फिर मैं खुद terminal में manually चलाता हूँ.
ऐसा करने पर यह समस्या ज़रूर है कि छोटी-मोटी चीज़ें तो मैं खुद हाथ से ठीक करूँ तो ज़्यादा तेज़ होता है, लेकिन AI अपनी मर्ज़ी से कुछ अजीब छेड़छाड़ करके गड़बड़ कर दे, उससे तो यह बेहतर है. आखिरकार अगर वह production environment में फटता है, तो ज़िम्मेदारी मेरी ही होगी, है ना?
Goodhart के नियम का खंडन करने वाले एक उद्धरण के रूप में
मैंने Peter Drucker से जोड़ा जाने वाला यह कथन याद किया: "अगर आप इसे माप नहीं सकते, तो आप इसे प्रबंधित नहीं कर सकते (If you Can't measure it, you Can't manage it)"।
और खोजने पर पता चला कि Drucker Institute भी कहता है कि Drucker ने ऐसा कभी नहीं कहा।
बल्कि मुझे इसका उल्टा कथन मिला।
यह मान लेना गलत है कि अगर आप किसी चीज़ को माप नहीं सकते, तो आप उसे प्रबंधित नहीं कर सकते। — यह एक महंगा मिथक है। (It is wrong to suppose that if you can't measure it, you cant manage it-a costly myth) - Edward Deming
AI से यह पूछना कि आपको कितना स्वायत्तता और अधिकार दिया जाना चाहिए, अपने-आप में थोड़ा अर्थपूर्ण लगता है।
जब CEO किसी कर्मचारी से पूछे, "तुम्हें कितना अधिकार दिया जाए तो अच्छा लगेगा?" और वह जवाब दे, "अच्छा होगा अगर मुझे कंपनी का पूरा अधिकार दे दिया जाए," तो क्या वैसा ही एहसास होगा? CEO इसे अच्छा जवाब मानेगा या सोचेगा कि यह कर्मचारी अभी सामाजिक रूप से उतना परिपक्व नहीं है, यह उसकी पसंद पर निर्भर करेगा...
फिर भी, मुझे लगता है कि AI को कितना अधिकार दिया जाना चाहिए, यह AI से ज़्यादा उन डेवलपर्स, मैनेजमेंट और लोगों से पूछा जाना चाहिए जो AI का इस्तेमाल करते हैं।
कभी-कभी कंपनी के intranet पर चलने वाले frontend में थोड़ा-बहुत बदलाव करना पड़ता है, और एक बार मैंने अधिकारियों के देखने वाले dashboard में ☰ ⋮ ⋯ + जैसे आइकन डाल दिए थे, तो उसके लिए डांट खानी पड़ी थी। वे पूछ रहे थे कि अमुक-अमुक फीचर कहाँ गया, और जब मैंने कहा कि यह बटन दबाइए, तो बोले कि दिखता ही नहीं, बस इसे टेक्स्ट में लिखो वगैरह... आखिरकार उसे फिर से उसी 2000s वाले interface पर वापस करना पड़ा, जो पहले इस्तेमाल होता था। बाकी चीज़ों की तरह, frontend सच में मुश्किल है।
लगता है Tesla हो या Rivian, दोनों ही अपनी खुद की chips बनाने की दिशा में जा रहे हैं। बेशक, इस घोषणा के बाद शेयर कीमत 10% तक गिर गई।
मैं Rivian को टेस्ट ड्राइव तो नहीं कर पाया, बस उसमें बैठकर ही देखा, लेकिन इसकी build quality वाकई बहुत अच्छी लगी।
कोरिया में भी 2021 में ही trademark और patent registration हो चुका था, लेकिन लॉन्च की कोई खबर सुनने को नहीं मिली।
अगर कोई यह दावा करता है कि उसके पास सोने के अंडे देने वाली हंस है, तो क्या हमें यह परखने में सक्षम नहीं होना चाहिए कि वे अंडे सचमुच सोने के हैं, क्या सच में वही हंस उन्हें दे रही है, और उन सोने के अंडों के बदले वह क्या ले रही है?
मैं स्टॉलमैन की उस दलील को, जिसमें वे कहते हैं कि भरोसेमंद computing के लिए source तक पहुंच होनी चाहिए, कुछ इसी भाव में पढ़ता हूं.
हाल ही में चीन की embedded platform निर्माता sipeed के nanokvm नाम के एक प्रोडक्ट में microphone पाए जाने का मामला सामने आया था.
मुझे पता है कि चीन में बने embedded प्रोडक्ट्स को लेकर यह आशंका रहती है कि वे security के लिहाज से कमजोर हो सकते हैं, या यहां तक कि कहीं उनका इस्तेमाल सरकारी security operations में तो नहीं हो रहा.
शायद उसी पूर्वाग्रह का असर था कि हाल में उस प्रोडक्ट पर ऐसा एक लेख भी आया था: https://hi.news.hada.io/topic?id=24886
लेकिन मेरा मानना है कि sipeed ने hardware से लेकर software development तक सब कुछ open source में किया था, इसलिए वह इस गलतफहमी से बाहर आ सका: https://x.com/lexifdev/status/1999340940805439775
स्टॉलमैन के दौर में, मेरी जानकारी में, ऐसी बहसों में चीन सरकार की जगह उस समय की अमेरिकी सरकार और NSA हुआ करते थे, जब McCarthyism का असर अभी बाकी था.
जो बातें कभी conspiracy theory लगती थीं, उनमें से NSA backdoor के कुछ मामले बाद में सच भी निकले, और printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) जैसी चीजें भी रही हैं.
इन दिनों सरकार से जुड़ी conspiracy theories की तुलना में यह बात ज्यादा चर्चा में रहती है कि जिन कंपनियों की मुख्य कमाई advertising से होती है, वे targeted ads के लिए smartphone के microphone से जासूसी करती हैं.
और software technology कंपनियों में source code की भूमिका निश्चित रूप से बड़ी होती है, लेकिन मेरा मानना है कि overall convenience, service operations की क्षमता, और trust उससे भी बड़ी भूमिका निभाते हैं.
सिर्फ OpenAI का source code मिल जाने भर से क्या बाद में आने वाले खिलाड़ी आसानी से ऐसा infrastructure स्थिर रूप से हासिल और संचालित कर पाएंगे जो बड़ी संख्या में users को संभाल सके, और brand trust में भी उसकी बराबरी कर सकें?
ऐसे काफी उदाहरण हैं जहां मुख्य product open source होने के बावजूद, और उसके अनगिनत forks होने के बावजूद, मूल पक्ष ने नेतृत्व नहीं खोया.
अभी तुरंत जो उदाहरण दिमाग में आते हैं, उनमें Chrome और VS Code भी हैं.
बेशक, नेतृत्व खोने के उदाहरण भी हैं, जैसे Elastic या Redis के साथ open source license को लेकर AWS की वजह से हुए विवाद, लेकिन वहां भी मेरा मानना है कि बात इसलिए बनी क्योंकि वे दोनों कंपनियां AWS की तुलना में convenience, service operations की क्षमता, और trust में अपेक्षाकृत पीछे थीं.
खैर, इस तरह की बातें एक मायने में राजनीतिक और वैचारिक बहस भी हैं. इसलिए एक निजी बात जोड़ना चाहूंगा.
मैं पेशे से software development करता हूं, और शौक में embedded hardware से छेड़छाड़ करता हूं; इस नजरिए से कहूं तो source code, circuit diagram जैसी चीजें न हों और सामने सिर्फ black box हो, तो development और maintenance करना सचमुच बहुत मुश्किल हो जाता है.
जब किसी software library या hardware का उपयोग करके कुछ develop करना होता है, तब अगर source code या design documents मिल सकें, या कम से कम spec documents ही अच्छी तरह व्यवस्थित हों, तो development बहुत आसान हो जाता है; नहीं तो सच में सिरदर्द हो जाता है.
हाल में विदेशों में right to repair की बात काफी उठी थी. उनमें एक बात मुझे खास लगी: पहले electronic devices का ढक्कन खोलने पर, मरम्मत में मदद के लिए उनके भीतर wiring diagram बना होता था. (हाल में Apple मरम्मत करने वालों को circuit diagram उपलब्ध कराता है, ऐसा सुना है.)
ऐसे अनुभव उन products पर भरोसा बनने में बहुत बड़ा असर डालते हैं. आजकल जब मैं कोई तकनीक चुनता हूं या कोई product खरीदता हूं, तो सबसे पहले यह देखता हूं कि अगर यह खराब हो जाए या इसमें कोई समस्या आए, तो क्या मैं इसे आसानी से समझकर ठीक कर सकता हूं, या कम से कम कोई workaround निकालकर इस्तेमाल कर सकता हूं.
काम का नाम तो पहले ही कोई न कोई इस्तेमाल कर रहा है।
GitHub को दोष देते देखो तो यह बस RMS-स्टाइल की बेवजह की आलोचना लगती है lol
Apple के आधिकारिक release note में सिर्फ एक पंक्ति है कि "RDMA over Thunderbolt" संभव हो गया है, इसलिए मैंने GN+ के लिए अतिरिक्त व्याख्या लिखी है.
अरे, मैंने सिर्फ़ मुख्य लेख देखा था, शीर्षक नहीं था... sob
लेखक: देखा न
मेरा वज़न ग्राफ़ ऊपर की ओर जा रहा है।
क्या किसी को पता है कि
emacsका मतलब क्या है? मतलब तो है, लेकिन ऐसे acronym वाले नाम एक नज़र में समझ भी नहीं आते, और आखिरकार यह एक नाम ही है… और अब सिर्फ़ फ़ंक्शन के आधार पर नाम रखने के लिए प्रोजेक्ट्स की संख्या भी बहुत ज़्यादा हो चुकी है।OMSCS के credits पूरे कर लें तो graduation हो जाता है। thesis नहीं लिखनी पड़ती।
AI को अधिकार देना आखिरकार इंसान ही करते हैं, लेकिन व्यावहारिक रूप से मुझे लगता है कि AI को कम से कम अभी से भी अधिक बड़े अधिकार और स्वायत्तता मिलने की संभावना काफी अधिक है.
अभी के रुझान को देखें तो AI को इंसानों की जगह कुछ काम सौंपने का दायरा धीरे-धीरे बढ़ता जा रहा है. रिपोर्ट लिखने या vibe coding ही नहीं, बल्कि web browser या यहाँ तक कि robots के ज़रिये chat interface के बाहर की दुनिया पर भी असर डालने लायक बनाने की दिशा में रुझान है.
अगर ऐसा है, तो management अंततः चाहेगा कि किसी खास काम या क्षेत्र में AI इंसानों को पूरी तरह replace कर दे, और यदि यह संभव हो जाता है, तो कम से कम उस दायरे में AI के पास इंसान के बराबर अधिकार और स्वायत्तता होगी.
इसलिए मुझे लगता है कि हमें यह मानकर चलना चाहिए कि भविष्य में कभी AI को इंसान-स्तर के अधिकार मिलने की संभावना भी काफी अधिक है.
ऐसी स्थिति में, जब इतना अधिक अधिकार और स्वायत्तता दी जाएगी, तब AI कैसे व्यवहार करता है, यह महत्वपूर्ण होना ही है.
इस हिस्से को संरचनात्मक रूप से कैसे संभालना बेहतर होगा, इस बारे में GPT series की प्रतिक्रियाओं में अच्छी तरह व्यवस्थित किया गया है. वहाँ कहा गया है कि explicit scope definition, authority separation, कई स्तरों पर prior/post supervision, और इंसानों के पास AI में हस्तक्षेप करने के कई साधन होने चाहिए. जहाँ physical intervention संभव हो, वहाँ तो शुरू से ही AI को पूर्ण autonomy देना अनुचित है. लेकिन उस स्थिति में भी, human-in-the-loop की व्यवस्था भी कभी न कभी कमजोर पड़ सकती है.
संदर्भ के लिए, मैं काम के दौरान मुख्य रूप से 3 हिस्सों में AI का उपयोग करता हूँ: document या email writing, existing code और current issue analysis, और issue के अनुसार code generation तथा modification.
इसमें document या email जैसी चीज़ों के मामले में मैं बस output को खुद पढ़कर वैसा ही इस्तेमाल कर लेता हूँ, या थोड़ा-बहुत ठीक करके लिख देता हूँ. लेकिन जहाँ code generation या modification शामिल हो, वहाँ मैं कहीं ज़्यादा conservative तरीके से इस्तेमाल करता हूँ. सिर्फ़ मोटे तौर पर "इसे थोड़ा ठीक कर दो" कह देने पर AI मेरे निर्देश को अस्पष्ट ढंग से समझ लेता है, या कभी-कभी उन हिस्सों को भी अपनी तरफ़ से छेड़ देता है जिनका मैंने ज़िक्र तक नहीं किया था.
इसलिए code modification से पहले मैं STICC के अनुसार spec document हमेशा पहले पेश करने और explicit approval लेने की बात global prompt में तय करके रखी है, और वास्तविक modification का काम केवल spec में लिखी बातों तक ही सीमित रखता हूँ. modification के बाद diff भी मैं पूरा खुद जाँचता हूँ. और build जैसे commands चलाने के लिए भी या तो हमेशा मेरी approval ली जाती है, या फिर मैं खुद terminal में manually चलाता हूँ.
ऐसा करने पर यह समस्या ज़रूर है कि छोटी-मोटी चीज़ें तो मैं खुद हाथ से ठीक करूँ तो ज़्यादा तेज़ होता है, लेकिन AI अपनी मर्ज़ी से कुछ अजीब छेड़छाड़ करके गड़बड़ कर दे, उससे तो यह बेहतर है. आखिरकार अगर वह production environment में फटता है, तो ज़िम्मेदारी मेरी ही होगी, है ना?
Goodhart के नियम का खंडन करने वाले एक उद्धरण के रूप में
मैंने Peter Drucker से जोड़ा जाने वाला यह कथन याद किया: "अगर आप इसे माप नहीं सकते, तो आप इसे प्रबंधित नहीं कर सकते (If you Can't measure it, you Can't manage it)"।
और खोजने पर पता चला कि Drucker Institute भी कहता है कि Drucker ने ऐसा कभी नहीं कहा।
बल्कि मुझे इसका उल्टा कथन मिला।
यह मान लेना गलत है कि अगर आप किसी चीज़ को माप नहीं सकते, तो आप उसे प्रबंधित नहीं कर सकते। — यह एक महंगा मिथक है। (It is wrong to suppose that if you can't measure it, you cant manage it-a costly myth) - Edward Deming
अच्छी जानकारी के लिए धन्यवाद :D
AI से यह पूछना कि आपको कितना स्वायत्तता और अधिकार दिया जाना चाहिए, अपने-आप में थोड़ा अर्थपूर्ण लगता है।
जब CEO किसी कर्मचारी से पूछे, "तुम्हें कितना अधिकार दिया जाए तो अच्छा लगेगा?" और वह जवाब दे, "अच्छा होगा अगर मुझे कंपनी का पूरा अधिकार दे दिया जाए," तो क्या वैसा ही एहसास होगा? CEO इसे अच्छा जवाब मानेगा या सोचेगा कि यह कर्मचारी अभी सामाजिक रूप से उतना परिपक्व नहीं है, यह उसकी पसंद पर निर्भर करेगा...
फिर भी, मुझे लगता है कि AI को कितना अधिकार दिया जाना चाहिए, यह AI से ज़्यादा उन डेवलपर्स, मैनेजमेंट और लोगों से पूछा जाना चाहिए जो AI का इस्तेमाल करते हैं।
मैंने इसे जल्दी-जल्दी बदल दिया था, लेकिन बाहर तो यह वैसे ही प्रकाशित हो गया था T_T
कभी-कभी कंपनी के intranet पर चलने वाले frontend में थोड़ा-बहुत बदलाव करना पड़ता है, और एक बार मैंने अधिकारियों के देखने वाले dashboard में ☰ ⋮ ⋯ + जैसे आइकन डाल दिए थे, तो उसके लिए डांट खानी पड़ी थी। वे पूछ रहे थे कि अमुक-अमुक फीचर कहाँ गया, और जब मैंने कहा कि यह बटन दबाइए, तो बोले कि दिखता ही नहीं, बस इसे टेक्स्ट में लिखो वगैरह... आखिरकार उसे फिर से उसी 2000s वाले interface पर वापस करना पड़ा, जो पहले इस्तेमाल होता था। बाकी चीज़ों की तरह, frontend सच में मुश्किल है।
टाइटल
killsहो गया.. हाहाहालगता है Tesla हो या Rivian, दोनों ही अपनी खुद की chips बनाने की दिशा में जा रहे हैं। बेशक, इस घोषणा के बाद शेयर कीमत 10% तक गिर गई।
मैं Rivian को टेस्ट ड्राइव तो नहीं कर पाया, बस उसमें बैठकर ही देखा, लेकिन इसकी build quality वाकई बहुत अच्छी लगी।
कोरिया में भी 2021 में ही trademark और patent registration हो चुका था, लेकिन लॉन्च की कोई खबर सुनने को नहीं मिली।
समझने के लिए धन्यवाद.
अगर कोई यह दावा करता है कि उसके पास सोने के अंडे देने वाली हंस है, तो क्या हमें यह परखने में सक्षम नहीं होना चाहिए कि वे अंडे सचमुच सोने के हैं, क्या सच में वही हंस उन्हें दे रही है, और उन सोने के अंडों के बदले वह क्या ले रही है?
मैं स्टॉलमैन की उस दलील को, जिसमें वे कहते हैं कि भरोसेमंद computing के लिए source तक पहुंच होनी चाहिए, कुछ इसी भाव में पढ़ता हूं.
हाल ही में चीन की embedded platform निर्माता sipeed के nanokvm नाम के एक प्रोडक्ट में microphone पाए जाने का मामला सामने आया था.
मुझे पता है कि चीन में बने embedded प्रोडक्ट्स को लेकर यह आशंका रहती है कि वे security के लिहाज से कमजोर हो सकते हैं, या यहां तक कि कहीं उनका इस्तेमाल सरकारी security operations में तो नहीं हो रहा.
शायद उसी पूर्वाग्रह का असर था कि हाल में उस प्रोडक्ट पर ऐसा एक लेख भी आया था: https://hi.news.hada.io/topic?id=24886
लेकिन मेरा मानना है कि sipeed ने hardware से लेकर software development तक सब कुछ open source में किया था, इसलिए वह इस गलतफहमी से बाहर आ सका: https://x.com/lexifdev/status/1999340940805439775
स्टॉलमैन के दौर में, मेरी जानकारी में, ऐसी बहसों में चीन सरकार की जगह उस समय की अमेरिकी सरकार और NSA हुआ करते थे, जब McCarthyism का असर अभी बाकी था.
जो बातें कभी conspiracy theory लगती थीं, उनमें से NSA backdoor के कुछ मामले बाद में सच भी निकले, और printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) जैसी चीजें भी रही हैं.
इन दिनों सरकार से जुड़ी conspiracy theories की तुलना में यह बात ज्यादा चर्चा में रहती है कि जिन कंपनियों की मुख्य कमाई advertising से होती है, वे targeted ads के लिए smartphone के microphone से जासूसी करती हैं.
और software technology कंपनियों में source code की भूमिका निश्चित रूप से बड़ी होती है, लेकिन मेरा मानना है कि overall convenience, service operations की क्षमता, और trust उससे भी बड़ी भूमिका निभाते हैं.
सिर्फ OpenAI का source code मिल जाने भर से क्या बाद में आने वाले खिलाड़ी आसानी से ऐसा infrastructure स्थिर रूप से हासिल और संचालित कर पाएंगे जो बड़ी संख्या में users को संभाल सके, और brand trust में भी उसकी बराबरी कर सकें?
ऐसे काफी उदाहरण हैं जहां मुख्य product open source होने के बावजूद, और उसके अनगिनत forks होने के बावजूद, मूल पक्ष ने नेतृत्व नहीं खोया.
अभी तुरंत जो उदाहरण दिमाग में आते हैं, उनमें Chrome और VS Code भी हैं.
बेशक, नेतृत्व खोने के उदाहरण भी हैं, जैसे Elastic या Redis के साथ open source license को लेकर AWS की वजह से हुए विवाद, लेकिन वहां भी मेरा मानना है कि बात इसलिए बनी क्योंकि वे दोनों कंपनियां AWS की तुलना में convenience, service operations की क्षमता, और trust में अपेक्षाकृत पीछे थीं.
खैर, इस तरह की बातें एक मायने में राजनीतिक और वैचारिक बहस भी हैं. इसलिए एक निजी बात जोड़ना चाहूंगा.
मैं पेशे से software development करता हूं, और शौक में embedded hardware से छेड़छाड़ करता हूं; इस नजरिए से कहूं तो source code, circuit diagram जैसी चीजें न हों और सामने सिर्फ black box हो, तो development और maintenance करना सचमुच बहुत मुश्किल हो जाता है.
जब किसी software library या hardware का उपयोग करके कुछ develop करना होता है, तब अगर source code या design documents मिल सकें, या कम से कम spec documents ही अच्छी तरह व्यवस्थित हों, तो development बहुत आसान हो जाता है; नहीं तो सच में सिरदर्द हो जाता है.
हाल में विदेशों में right to repair की बात काफी उठी थी. उनमें एक बात मुझे खास लगी: पहले electronic devices का ढक्कन खोलने पर, मरम्मत में मदद के लिए उनके भीतर wiring diagram बना होता था. (हाल में Apple मरम्मत करने वालों को circuit diagram उपलब्ध कराता है, ऐसा सुना है.)
ऐसे अनुभव उन products पर भरोसा बनने में बहुत बड़ा असर डालते हैं. आजकल जब मैं कोई तकनीक चुनता हूं या कोई product खरीदता हूं, तो सबसे पहले यह देखता हूं कि अगर यह खराब हो जाए या इसमें कोई समस्या आए, तो क्या मैं इसे आसानी से समझकर ठीक कर सकता हूं, या कम से कम कोई workaround निकालकर इस्तेमाल कर सकता हूं.
आपने बिल्कुल सही देखा है
स्टॉलमैन यह भी कहते हैं कि SaaS का भी इस्तेमाल नहीं करना चाहिए
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
यह कुछ ceramic mood जैसा लग रहा है।
मेरी सैलरी की बढ़ोतरी का ग्राफ पिछले 5 सालों से 0% पर है।