हर किसी के पास समान accessibility नहीं होती। साल 2100 में अपने बारे में सोचिए। जब हम किसी एक service को भी ठीक से इस्तेमाल न कर पाने के कारण जूझ रहे होंगे, तब 21वीं सदी के आखिर के हमारे दोस्त हमारे बारे में क्या कहेंगे।
10/1h की जगह 60/6h, 30/3h जैसी सीमा ही रखी होती तो उतना अफसोस नहीं होता; जैसा दूसरी टिप्पणियों में कहा गया, लगता है कि अकाउंट बनवाने के लिए प्रोत्साहित करना भी इसका काफी बड़ा मकसद है...
मेरी व्यक्तिगत राय में,
मुझे याद है कि कुछ versions में Docker installation process के दौरान लॉगिन को अनिवार्य करने वाले versions भी थे,
इसलिए ऐसा भी लगता है कि इसका मकसद Docker अकाउंट बनवाने के लिए प्रेरित करना हो सकता है।
यह तो जैसे "स्मार्टफोन-रहित" होने को मजबूर करना है; लेकिन transport या finance जैसी ज़रूरी infrastructure को फोन के बिना इस्तेमाल करना मुश्किल हो, तो यह सच में समस्या है.
मैंने music AI Suno AI का अकाउंट बनाया था, फिर उसे delete करने की कोशिश की, लेकिन वेबसाइट पर बाकी काम तो हो रहे थे पर account deletion blocked था.
delete करना सिर्फ app में ही possible है... app install नहीं करना चाहता, इसलिए एक mail भेजकर इंतज़ार कर रहा हूँ.
पहले अलग SW install करना आसान होने वाली चीज़ों को भी ज़बरदस्ती web पर ठूँसकर browser से access कराना trend था, लेकिन आजकल उसका उल्टा हो गया है, यह दिलचस्प है.
यह तो किसी हद तक लाज़िमी है कि इन्फ्रास्ट्रक्चर बहुसंख्यक लोगों के लिए बनाया जाए। इसे "ऐप का अत्याचार" कहा जा रहा है, और उदाहरणों में यह भी शामिल है कि किसी को निजी कंपनियों की discount benefits नहीं मिल पातीं, लेकिन क्या उसे वाकई अत्याचार कहा जा सकता है..? यह तो ऐसी दुनिया है जहाँ 100 डॉलर के फ़ोन भी बिकते हैं..
अब तक कोई सीमा नहीं थी, यह बात ही ज़्यादा हैरान करने वाली लगती है... फिर भी प्रति घंटे 10 बार तो बहुत कम है।
खासकर जिन docker-compose सेटअप में रेफ़रेंस की जाने वाली इमेज 10 से ज़्यादा हैं, उन्हें बिना authentication के इस्तेमाल नहीं किया जा सकेगा, यह काफ़ी अफ़सोसजनक है। (उदाहरण के तौर पर, supabase कुल 12 इमेज को रेफ़रेंस करता है.)
Google जैसी ग्लोबल कंपनियां भी शायद तीन या उससे ज़्यादा क्षेत्रों में infrastructure engineers तैनात करके 24/7 reliability सुनिश्चित करती होंगी—क्या ऐसा ही है?
यह वैसा ही है जैसे अगर आप अपना email server खुद चलाते हैं, तो spam से निपटना भी आपको खुद ही करना पड़ता है.
अगर विज्ञापन/spam अकाउंट सिर्फ एक server बनाकर spam फैलाते हैं, तो server admin के स्तर पर बस उस server को block कर देना काफी होता है.
लेकिन federated नेटवर्क कोई नई चीज़ नहीं है, इसलिए काफी छोड़े हुए server (instance) भी मौजूद हैं. ऐसे serverों के रास्ते कई serverों के कई users को spam भेजने वाले ctkpaarr नाम के spam की एक बार काफी भरमार हुई थी. बेशक, इसका सामना भी हर server को अपने-अपने स्तर पर खुद ही करना पड़ा था.
Memory safety को ध्यान में रखें तो Rust को अपनाना शायद टालना मुश्किल बदलाव है। शायद कोई उचित समझौता निकालकर फिर से जोड़ने की कोशिश की जाएगी।
लेकिन, व्यक्तिगत रूप से मुझे Rust के keywords नज़र में आसानी से नहीं बैठते, और काफ़ी समय बाद दोबारा देखने पर उन्हें याद करना भी आसान नहीं लगता, इसलिए उस पर हाथ ठीक से नहीं जम पाता ;;;; मुझे पता है कि ये सब ज़रूरी चीज़ें हैं, लेकिन कभी-कभी यह अंग्रेज़ी के irregular verbs को ज़बरदस्ती रटने जैसा महसूस होता है। फिर भी, यह भी सच है कि Rust में लिखे गए नतीजे वास्तविक कामकाजी माहौल में कम समस्याएँ पैदा करते हैं.....
आह, यहाँ Docker वर्ज़न से मतलब Docker Desktop है
20 साल पहले की लिखी हुई चीज़ को फिर से देखा… लगा जैसे टाइम स्लिप हो गया हो, हाहा
हर किसी के पास समान accessibility नहीं होती। साल 2100 में अपने बारे में सोचिए। जब हम किसी एक service को भी ठीक से इस्तेमाल न कर पाने के कारण जूझ रहे होंगे, तब 21वीं सदी के आखिर के हमारे दोस्त हमारे बारे में क्या कहेंगे।
अहा? तो पहले से भी कोई सीमा थी, हाहा.
10/1h की जगह 60/6h, 30/3h जैसी सीमा ही रखी होती तो उतना अफसोस नहीं होता; जैसा दूसरी टिप्पणियों में कहा गया, लगता है कि अकाउंट बनवाने के लिए प्रोत्साहित करना भी इसका काफी बड़ा मकसद है...
(बदलाव)
(पहले)
मेरी व्यक्तिगत राय में,
मुझे याद है कि कुछ versions में Docker installation process के दौरान लॉगिन को अनिवार्य करने वाले versions भी थे,
इसलिए ऐसा भी लगता है कि इसका मकसद Docker अकाउंट बनवाने के लिए प्रेरित करना हो सकता है।
पहले
मुझे याद है कि ऐसी सीमा थी
लगता है Docker registry proxy & cache solution अब अनिवार्य हो जाएगा
यह तो जैसे "स्मार्टफोन-रहित" होने को मजबूर करना है; लेकिन transport या finance जैसी ज़रूरी infrastructure को फोन के बिना इस्तेमाल करना मुश्किल हो, तो यह सच में समस्या है.
मैंने music AI Suno AI का अकाउंट बनाया था, फिर उसे delete करने की कोशिश की, लेकिन वेबसाइट पर बाकी काम तो हो रहे थे पर account deletion blocked था.
delete करना सिर्फ app में ही possible है... app install नहीं करना चाहता, इसलिए एक mail भेजकर इंतज़ार कर रहा हूँ.
पहले अलग SW install करना आसान होने वाली चीज़ों को भी ज़बरदस्ती web पर ठूँसकर browser से access कराना trend था, लेकिन आजकल उसका उल्टा हो गया है, यह दिलचस्प है.
यह तो किसी हद तक लाज़िमी है कि इन्फ्रास्ट्रक्चर बहुसंख्यक लोगों के लिए बनाया जाए। इसे "ऐप का अत्याचार" कहा जा रहा है, और उदाहरणों में यह भी शामिल है कि किसी को निजी कंपनियों की discount benefits नहीं मिल पातीं, लेकिन क्या उसे वाकई अत्याचार कहा जा सकता है..? यह तो ऐसी दुनिया है जहाँ 100 डॉलर के फ़ोन भी बिकते हैं..
प्लीज़ TTTT Libre बहुत महंगा है...
अब तक कोई सीमा नहीं थी, यह बात ही ज़्यादा हैरान करने वाली लगती है... फिर भी प्रति घंटे 10 बार तो बहुत कम है।
खासकर जिन
docker-composeसेटअप में रेफ़रेंस की जाने वाली इमेज 10 से ज़्यादा हैं, उन्हें बिना authentication के इस्तेमाल नहीं किया जा सकेगा, यह काफ़ी अफ़सोसजनक है। (उदाहरण के तौर पर, supabase कुल 12 इमेज को रेफ़रेंस करता है.)Google जैसी ग्लोबल कंपनियां भी शायद तीन या उससे ज़्यादा क्षेत्रों में infrastructure engineers तैनात करके 24/7 reliability सुनिश्चित करती होंगी—क्या ऐसा ही है?
"OpenAI के 300 million साप्ताहिक उपयोगकर्ताओं वाला ChatGPT"
मूल लेख में 300M लिखा है, इसलिए कृपया इसे 30 करोड़ में ठीक कर दें।
DeepSeek वाकई काफ़ी दिलचस्प कदम उठा रहा है। यह देखने की उत्सुकता है कि क्या-क्या सार्वजनिक किया जाएगा।
2 लाख करोड़ रुपये के पैमाने पर Bybit हैक: ऑपरेशनल सुरक्षा विफलता के युग का आगमन
यह वैसा ही है जैसे अगर आप अपना email server खुद चलाते हैं, तो spam से निपटना भी आपको खुद ही करना पड़ता है.
अगर विज्ञापन/spam अकाउंट सिर्फ एक server बनाकर spam फैलाते हैं, तो server admin के स्तर पर बस उस server को block कर देना काफी होता है.
लेकिन federated नेटवर्क कोई नई चीज़ नहीं है, इसलिए काफी छोड़े हुए server (instance) भी मौजूद हैं. ऐसे serverों के रास्ते कई serverों के कई users को spam भेजने वाले
ctkpaarrनाम के spam की एक बार काफी भरमार हुई थी. बेशक, इसका सामना भी हर server को अपने-अपने स्तर पर खुद ही करना पड़ा था.https://qiita.com/gnh1201/items/09f4081f84610db3a9d3
https://github.com/warpKaiba/kuroAntiSpam
https://github.com/Interstellar-Relay-Community/budae-jjigae
Memory safety को ध्यान में रखें तो Rust को अपनाना शायद टालना मुश्किल बदलाव है। शायद कोई उचित समझौता निकालकर फिर से जोड़ने की कोशिश की जाएगी।
लेकिन, व्यक्तिगत रूप से मुझे Rust के keywords नज़र में आसानी से नहीं बैठते, और काफ़ी समय बाद दोबारा देखने पर उन्हें याद करना भी आसान नहीं लगता, इसलिए उस पर हाथ ठीक से नहीं जम पाता ;;;; मुझे पता है कि ये सब ज़रूरी चीज़ें हैं, लेकिन कभी-कभी यह अंग्रेज़ी के irregular verbs को ज़बरदस्ती रटने जैसा महसूस होता है। फिर भी, यह भी सच है कि Rust में लिखे गए नतीजे वास्तविक कामकाजी माहौल में कम समस्याएँ पैदा करते हैं.....
कंपनी में काम के लिए VMS इस्तेमाल होता है, लेकिन command-line shell DCL, Windows या Unix से इतना अलग है कि उससे परिचित होने में थोड़ा समय लगा।
खुशकिस्मती से GUI कम-से-कम कुछ हद तक परिचित CDE था, इसलिए राहत रही।