जैसे अतीत में dot-com, ब्लॉग और SaaS की लहरें आई थीं, वैसे ही आज अनगिनत AI apps बाजार में आ रहे हैं, लेकिन उनमें से ज़्यादातर बिना पहचान बनाए ही गायब हो जाने वाले हैं। ऐसे माहौल में जहाँ कोई भी AI से app बना सकता है, यदि कोई खास अंतर नहीं है तो बहुत जल्द app जैसा form factor ही अर्थहीन हो जाएगा। अब हम ऐसे दौर में प्रवेश कर रहे हैं जहाँ ज़रूरत के मुताबिक functions को AI तुरंत बनाता है और फिर हटा देता है — यानी 'अदृश्य software' का युग।
अगर smartphone के शुरुआती दौर के app development boom को याद करें, तो आज की स्थिति और स्पष्ट हो जाती है। अब AI development का मूल coding नहीं, बल्कि idea, design और execution capability है। स्वाभाविक रूप से कंपनियों के भीतर 'developer' की परिभाषा भी बदल रही है। लेकिन हक़ीक़त कड़ी है। कंपनियाँ AI के ज़रिए बेहद कम समय में development करने का दबाव डाल रही हैं, और जो काम पहले 2 हफ्ते लेता था उसे 2 दिनों में पूरा करने की मांग कर रही हैं। developers कभी-कभी personal projects में 'बनाने के मज़े' के आदी हो जाते हैं, लेकिन काम के रूप में development पहले से भी ज़्यादा कठोर श्रम-तीव्रता का रूप ले रहा है। (यह बात मुझे 90 के दशक के 'office automation' दौर की याद दिलाती है। office automation से काम आसान या आरामदायक नहीं हुआ था, बल्कि कम लोगों से और ज़्यादा काम करवाया जाने लगा था...)
हाल में चीन में AI की लहर सचमुच बहुत तेज़ है। मॉडल development से लेकर application programs तक, मात्रा और गुणवत्ता दोनों में वह अमेरिका के बराबर या बल्कि उससे आगे निकलता दिख रहा है। मेरी व्यक्तिपरक नज़र में अमेरिका के प्रमुख AI विभागों में काफ़ी कोर टैलेंट चीनी मूल के हैं.
जहाँ अमेरिकी कंपनियाँ privacy, token cost और security issues की वजह से सतर्क रुख़ अपनाती हैं, वहीं चीन अपेक्षाकृत अधिक आक्रामक दिखता है। कोरिया में अगर KakaoTalk के साथ integration हो जाए तो अच्छा होगा, लेकिन Kakao की ख़ास मज़बूत security protocols और closed ecosystem की वजह से बाहरी access आसान नहीं है। आख़िरकार या तो screen recognition AI के ज़रिए bypass automation वाले तरीके पर जाना पड़ेगा, या फिर AI services, KakaoTalk से अलग रास्ते पर जाएँगी। AI की इस लहर में ट्रेंड के बहाव में बहकर tools का दुरुपयोग करने के बजाय, शांत रहकर और संतुलित तरीके से प्रतिक्रिया देना ज़्यादा समझदारी लगता है.
अगर कंधे के ऊपर से देखकर लंबाई का पता चल जाना इतना गंभीर security vulnerability है, तो फिर Linux terminal तक पहुँच रखने वाले हर keyboard पर anti-peeping cover अनिवार्य क्यों नहीं कर दिया जाता? वरना सीधे keyboard को देख लो, या hidden camera से रिकॉर्ड कर लो, काम तो हो ही जाएगा।
सच कहूँ तो LLM services के frontend देखें तो लगता है ये आखिर ऐसा किस तरह बनाया गया है—इतना धीमा, features की कमी, और interaction भी इतना असुविधाजनक कि ऐसे लेख देखकर बस हँसी ही आती है।
सच कहूँ तो, जब तक वे अपने ही framework जैसे WinUI से पूरा user shell फिर से implement करने के स्तर की चीज़ नहीं करते, तब तक ज़्यादा उम्मीद नहीं है।
React में develop करना ही क्या असल में quality से ज़्यादा जल्दी-जल्दी कुछ बनाकर release करने के मकसद से नहीं होता?
फ़ोन का इस्तेमाल इसलिए नहीं करते क्योंकि उसका कोई विकल्प नहीं है। जब LG फ़ोन अच्छे बनाता था, तब लोग उन्हें काफ़ी इस्तेमाल करते थे। कंपनी ने खुद गलतियां कीं और उसी वजह से बर्बाद हुई।
ज़्यादातर नौकरीपेशा लोगों के लिए रहने की जगह चुनने का सबसे अहम मानदंड आने-जाने का समय होता है, इसलिए सियोल के बाहर तो स्वाभाविक रूप से विकल्प बन ही नहीं पाता। सरकार जब सार्वजनिक संस्थानों/कंपनियों को बाहर स्थानांतरित करने की कोशिश भी करती है, तो बहुत से लोग उसका विरोध करते हैं; पहले उसी बात की आलोचना करनी चाहिए।
मॉडल के मामले में, उसे लोकल पर चलाना आम लोगों के लिए पहले से ही असंभव है, और बाकी विकल्प भी बस उसी मॉडल में थोड़ा-सा प्रॉम्प्ट जोड़ देने के स्तर के हैं, न वे खास सस्ते हैं और न ही उनकी मार्केटिंग ठीक से की गई है। कोई उत्पाद कितना भी अच्छा हो, अगर लोगों को उसके बारे में पता ही न हो तो जाहिर है कि वह बिकेगा नहीं।
ईमानदारी से कहूं तो यह वैसा ही लगता है जैसे "बस कोरियाई लोगों की यही खासियत है~" कहकर बिना ज्यादा सोचे-समझे केवल ध्यान खींचने वाले shorts देख कर पोस्ट कर दिया गया हो।
अगर कोई इसे कंधे के ऊपर से देख सकता है, तो शायद इस बात की ज़्यादा चिंता होनी चाहिए कि टाइप करती हुई उंगलियाँ ही दिख रही हैं, है न...
इतनी दूरी पर तो आवाज़ रिकॉर्ड करके यह भी गिना जा सकता है कि कितने अक्षर हैं।
अगर सुरक्षा को लेकर इतनी चिंता है और जगह इतनी महत्वपूर्ण है, तो आपको physical security key इस्तेमाल करनी चाहिए।
मज़ाक वाकई बहुत बड़ी बाधा है। अगर humor sense वाला AI बना लिया जाए, तो वही असली innovation होगा। अभी उसे मज़ाक करने को कहो, तो कितना ज़बरदस्त non-funny निकलता है, उससे ही समझ आ जाता है।
प्रोडक्टिविटी बढ़ाने में इसका असर निश्चित रूप से है, लेकिन जैसे-जैसे सिस्टम जटिल होता जाता है, बुनियादी design या clean code जैसी समझ के बिना उस पर परत-दर-परत निर्माण करना आसान नहीं होता—यह craftsmanship की बात किए बिना भी हर कोई जानता है कि यह एक बुनियादी सच है।
टूल्स के बीच टकराव, किसी खास environment में असामान्य व्यवहार, या साधारण QoL features जैसी चीज़ों पर वास्तविक उपयोग के मामलों से आने वाला feedback हर project में बार-बार दिखाई देता है
अगर projects आपस में ऐसे हिस्सों को साझा नहीं करते, तो वही features बहुत से लोगों द्वारा बहुत सी भाषाओं में बार-बार विकसित करने पड़ते हैं
यहाँ तक कि xdg-desktop-portal भी हर environment के हिसाब से बिखरा हुआ है, इसलिए वही features अलग-अलग तरीकों और अलग-अलग प्रगति स्तरों के साथ विकसित किए जा रहे हैं.. development की स्थिति देखें तो तुरंत समझ आ जाएगा कि यह धीमा क्यों है
Wayland का इस्तेमाल करते हुए और issue व PR सिस्टम के पीछे-पीछे जाकर जो अनुभव हुआ है, उसके हिसाब से
यह एक simple protocol है, लेकिन standard implementation न होने की वजह से अलग-अलग जगहों पर बेतरतीब ढंग से development होता है, इसलिए प्रगति धीमी है.
और shared resources के लिए protocol को xdg-desktop-portal में अलग करके develop किया जाता है, इसलिए communication और decision process से गुजरते-गुजरते यह और भी धीमा लगता है.
उपयोगी और दूसरे desktop environments में मौजूद ज़्यादातर features implement हो चुके होने के बावजूद, उन्हें कई महीनों से लेकर कई सालों तक सिर्फ PR स्टेटस में ही अटके रहते हुए बहुत बार देखता हूँ.
सच कहूँ तो बिना सोचे-समझे किसी language को कोसना मेरी समझ से बाहर है.. कौन-सी language इस्तेमाल हो रही है और memory safety के बीच संबंध हो सकता है, लेकिन वह अनिवार्य नहीं है।
मृत इंटरनेट सिद्धांत...
https://github.com/opgginc/opencode-bar की सिफारिश करता/करती हूँ.
जैसे अतीत में dot-com, ब्लॉग और SaaS की लहरें आई थीं, वैसे ही आज अनगिनत AI apps बाजार में आ रहे हैं, लेकिन उनमें से ज़्यादातर बिना पहचान बनाए ही गायब हो जाने वाले हैं। ऐसे माहौल में जहाँ कोई भी AI से app बना सकता है, यदि कोई खास अंतर नहीं है तो बहुत जल्द app जैसा form factor ही अर्थहीन हो जाएगा। अब हम ऐसे दौर में प्रवेश कर रहे हैं जहाँ ज़रूरत के मुताबिक functions को AI तुरंत बनाता है और फिर हटा देता है — यानी 'अदृश्य software' का युग।
अगर smartphone के शुरुआती दौर के app development boom को याद करें, तो आज की स्थिति और स्पष्ट हो जाती है। अब AI development का मूल coding नहीं, बल्कि idea, design और execution capability है। स्वाभाविक रूप से कंपनियों के भीतर 'developer' की परिभाषा भी बदल रही है। लेकिन हक़ीक़त कड़ी है। कंपनियाँ AI के ज़रिए बेहद कम समय में development करने का दबाव डाल रही हैं, और जो काम पहले 2 हफ्ते लेता था उसे 2 दिनों में पूरा करने की मांग कर रही हैं। developers कभी-कभी personal projects में 'बनाने के मज़े' के आदी हो जाते हैं, लेकिन काम के रूप में development पहले से भी ज़्यादा कठोर श्रम-तीव्रता का रूप ले रहा है। (यह बात मुझे 90 के दशक के 'office automation' दौर की याद दिलाती है। office automation से काम आसान या आरामदायक नहीं हुआ था, बल्कि कम लोगों से और ज़्यादा काम करवाया जाने लगा था...)
हाल में चीन में AI की लहर सचमुच बहुत तेज़ है। मॉडल development से लेकर application programs तक, मात्रा और गुणवत्ता दोनों में वह अमेरिका के बराबर या बल्कि उससे आगे निकलता दिख रहा है। मेरी व्यक्तिपरक नज़र में अमेरिका के प्रमुख AI विभागों में काफ़ी कोर टैलेंट चीनी मूल के हैं.
जहाँ अमेरिकी कंपनियाँ privacy, token cost और security issues की वजह से सतर्क रुख़ अपनाती हैं, वहीं चीन अपेक्षाकृत अधिक आक्रामक दिखता है। कोरिया में अगर KakaoTalk के साथ integration हो जाए तो अच्छा होगा, लेकिन Kakao की ख़ास मज़बूत security protocols और closed ecosystem की वजह से बाहरी access आसान नहीं है। आख़िरकार या तो screen recognition AI के ज़रिए bypass automation वाले तरीके पर जाना पड़ेगा, या फिर AI services, KakaoTalk से अलग रास्ते पर जाएँगी। AI की इस लहर में ट्रेंड के बहाव में बहकर tools का दुरुपयोग करने के बजाय, शांत रहकर और संतुलित तरीके से प्रतिक्रिया देना ज़्यादा समझदारी लगता है.
चूँकि BM25 शब्द-केंद्रित खोज है, इसलिए galadbran की राय समझ में आने वाली लगती है।
अगर कंधे के ऊपर से देखकर लंबाई का पता चल जाना इतना गंभीर security vulnerability है, तो फिर Linux terminal तक पहुँच रखने वाले हर keyboard पर anti-peeping cover अनिवार्य क्यों नहीं कर दिया जाता? वरना सीधे keyboard को देख लो, या hidden camera से रिकॉर्ड कर लो, काम तो हो ही जाएगा।
सहमत हूँ।
पहले बात कर लेनी चाहिए, लेकिन बाद में ज़िम्मेदारी न लेने वाले रूप में यह आगे बढ़ रहा है।
ज़रा-सी बात पर "मर गया" वाले शीर्षक के लेख बहुत ज़्यादा हो गए हैं
तो लगता है कि यह काफ़ी थकाने वाला हो गया है
मुझे भी लगता है कि अब इन्हें मारना बंद कर देना चाहिए
सच कहूँ तो LLM services के frontend देखें तो लगता है ये आखिर ऐसा किस तरह बनाया गया है—इतना धीमा, features की कमी, और interaction भी इतना असुविधाजनक कि ऐसे लेख देखकर बस हँसी ही आती है।
सच कहूँ तो, जब तक वे अपने ही framework जैसे WinUI से पूरा user shell फिर से implement करने के स्तर की चीज़ नहीं करते, तब तक ज़्यादा उम्मीद नहीं है।
React में develop करना ही क्या असल में quality से ज़्यादा जल्दी-जल्दी कुछ बनाकर release करने के मकसद से नहीं होता?
फ़ोन का इस्तेमाल इसलिए नहीं करते क्योंकि उसका कोई विकल्प नहीं है। जब LG फ़ोन अच्छे बनाता था, तब लोग उन्हें काफ़ी इस्तेमाल करते थे। कंपनी ने खुद गलतियां कीं और उसी वजह से बर्बाद हुई।
ज़्यादातर नौकरीपेशा लोगों के लिए रहने की जगह चुनने का सबसे अहम मानदंड आने-जाने का समय होता है, इसलिए सियोल के बाहर तो स्वाभाविक रूप से विकल्प बन ही नहीं पाता। सरकार जब सार्वजनिक संस्थानों/कंपनियों को बाहर स्थानांतरित करने की कोशिश भी करती है, तो बहुत से लोग उसका विरोध करते हैं; पहले उसी बात की आलोचना करनी चाहिए।
मॉडल के मामले में, उसे लोकल पर चलाना आम लोगों के लिए पहले से ही असंभव है, और बाकी विकल्प भी बस उसी मॉडल में थोड़ा-सा प्रॉम्प्ट जोड़ देने के स्तर के हैं, न वे खास सस्ते हैं और न ही उनकी मार्केटिंग ठीक से की गई है। कोई उत्पाद कितना भी अच्छा हो, अगर लोगों को उसके बारे में पता ही न हो तो जाहिर है कि वह बिकेगा नहीं।
ईमानदारी से कहूं तो यह वैसा ही लगता है जैसे "बस कोरियाई लोगों की यही खासियत है~" कहकर बिना ज्यादा सोचे-समझे केवल ध्यान खींचने वाले shorts देख कर पोस्ट कर दिया गया हो।
अगर कोई इसे कंधे के ऊपर से देख सकता है, तो शायद इस बात की ज़्यादा चिंता होनी चाहिए कि टाइप करती हुई उंगलियाँ ही दिख रही हैं, है न...
इतनी दूरी पर तो आवाज़ रिकॉर्ड करके यह भी गिना जा सकता है कि कितने अक्षर हैं।
अगर सुरक्षा को लेकर इतनी चिंता है और जगह इतनी महत्वपूर्ण है, तो आपको physical security key इस्तेमाल करनी चाहिए।
मैं इसका विरोध करता हूँ।
यह वाकई बहुत शानदार खबर है।
मज़ाक वाकई बहुत बड़ी बाधा है। अगर humor sense वाला AI बना लिया जाए, तो वही असली innovation होगा। अभी उसे मज़ाक करने को कहो, तो कितना ज़बरदस्त non-funny निकलता है, उससे ही समझ आ जाता है।
प्रोडक्टिविटी बढ़ाने में इसका असर निश्चित रूप से है, लेकिन जैसे-जैसे सिस्टम जटिल होता जाता है, बुनियादी design या clean code जैसी समझ के बिना उस पर परत-दर-परत निर्माण करना आसान नहीं होता—यह craftsmanship की बात किए बिना भी हर कोई जानता है कि यह एक बुनियादी सच है।
टूल्स के बीच टकराव, किसी खास environment में असामान्य व्यवहार, या साधारण QoL features जैसी चीज़ों पर वास्तविक उपयोग के मामलों से आने वाला feedback हर project में बार-बार दिखाई देता है
अगर projects आपस में ऐसे हिस्सों को साझा नहीं करते, तो वही features बहुत से लोगों द्वारा बहुत सी भाषाओं में बार-बार विकसित करने पड़ते हैं
यहाँ तक कि xdg-desktop-portal भी हर environment के हिसाब से बिखरा हुआ है, इसलिए वही features अलग-अलग तरीकों और अलग-अलग प्रगति स्तरों के साथ विकसित किए जा रहे हैं.. development की स्थिति देखें तो तुरंत समझ आ जाएगा कि यह धीमा क्यों है
Wayland का इस्तेमाल करते हुए और issue व PR सिस्टम के पीछे-पीछे जाकर जो अनुभव हुआ है, उसके हिसाब से
यह एक simple protocol है, लेकिन standard implementation न होने की वजह से अलग-अलग जगहों पर बेतरतीब ढंग से development होता है, इसलिए प्रगति धीमी है.
और shared resources के लिए protocol को xdg-desktop-portal में अलग करके develop किया जाता है, इसलिए communication और decision process से गुजरते-गुजरते यह और भी धीमा लगता है.
उपयोगी और दूसरे desktop environments में मौजूद ज़्यादातर features implement हो चुके होने के बावजूद, उन्हें कई महीनों से लेकर कई सालों तक सिर्फ PR स्टेटस में ही अटके रहते हुए बहुत बार देखता हूँ.
आखिरकार यह तो एक protocol ही है, इसलिए अगर नए features बनाए भी जाएँ तो बस उन्हें मौजूदा protocol में define करना ही काफी होना चाहिए।
सच कहूँ तो बिना सोचे-समझे किसी language को कोसना मेरी समझ से बाहर है.. कौन-सी language इस्तेमाल हो रही है और memory safety के बीच संबंध हो सकता है, लेकिन वह अनिवार्य नहीं है।