Oct 20 3:03 AM PDT हम अधिकांश प्रभावित AWS Services में रिकवरी जारी रहने को देख रहे हैं। हम पुष्टि कर सकते हैं कि US-EAST-1 पर निर्भर global services और features भी रिकवर हो चुके हैं। हम पूरी तरह समाधान की दिशा में काम जारी रखे हुए हैं और जैसे ही साझा करने के लिए अधिक जानकारी होगी, हम अपडेट देंगे.
Oct 20 2:27 AM PDT हमें रिकवरी के स्पष्ट संकेत दिखाई दे रहे हैं। अब अधिकांश requests सफल होनी चाहिए। queued requests के backlog को कम करने पर हमारा काम जारी है। हम अतिरिक्त जानकारी देते रहेंगे।
कहा जा रहा है कि अधिकांश सेवाएं बहाल हो चुकी हैं। आगे मुआवजे की योजना क्या होगी, यह जानना दिलचस्प होगा।
Docker Hub भी उसी region में outage का असर झेल रहा है, इसलिए docker pull नहीं हो रहा और build नहीं कर पा रहे हैं.
फ़िलहाल Amazon ECR Public Gallery का इस्तेमाल कर रहे हैं. https://gallery.ecr.aws/
आजकल ध्यान भटकाने वाले माध्यम के रूप में स्मार्टफ़ोन का सबसे ज़्यादा नाम लिया जाता है। बेशक पहली नज़र में लोगों को इस ओर ले जाने वाले application बनाने वाले ज़िम्मेदार हैं, लेकिन मेरा मानना है कि अगर इसे सही तरह से इस्तेमाल करना आता हो तो यह समस्या हल की जा सकती है.
application की notifications को डिफ़ॉल्ट रूप से सब बंद कर देना चाहिए और सिर्फ़ ज़रूरी notifications ही छोड़नी चाहिए।
बची हुई notifications को भी अहमियत के हिसाब से बाँटना चाहिए, ताकि केवल बिल्कुल ज़रूरी notifications के लिए sound/vibration चालू हो और बाकी AOD या lock screen पर भी दिखाई न दें। अगर notification आपातकालीन नहीं है, तो जब चाहें notification सूची एक साथ देखी जा सकती है।
email के मामले में भी folders बाँटकर उन्हें अपने-आप classify होने देना चाहिए और सेटिंग ऐसी होनी चाहिए कि सिर्फ़ ज़रूरी चीज़ों की ही notification आए।
सिर्फ़ इतना कर लेने से भी स्मार्टफ़ोन की वजह से ध्यान बिखरने की चिंता नहीं रहेगी। बशर्ते कि आपको हर कुछ मिनट में स्मार्टफ़ोन देखने की आदत न हो.
यह एक बेहतरीन प्रोजेक्ट है। लेकिन इसका दायरा Hugo से काफ़ी हद तक ओवरलैप करता है.
स्पष्टीकरण मांगने वाले issue के जवाब में कहा गया है कि इसमें टर्मिनल में preview, तेज़ deployment, email newsletter system, और Obsidian theme जैसी चीज़ें हैं, लेकिन यह कोई बहुत असरदार बात नहीं लगती.
Markdown render करने वाले CLI tools बहुत हैं, और newsletter के लिए भी RSS/Atom को अपने-आप publish करने वाले features काफ़ी मिल जाते हैं..
लंबी अवधि में (खासकर दोहराए जाने वाले और अकुशल) श्रम को AI और रोबोट द्वारा प्रतिस्थापित किया जाना सही है। लेकिन इसके साथ यह भी ज़रूरी होगा कि वितरण प्रणाली में बदलाव आए, ताकि सारा अतिरिक्त मूल्य केवल उत्पादकों के पास ही न चला जाए।
असल में अगर आप इसे इस तरह समझें कि software engineering में सीखी गई चीज़ों को Markdown में किया जा रहा है, तो यह आसान और व्यावहारिक है। बस requirements specification अच्छे से लिखनी आती हो, वही काफ़ी है।
मुझे नहीं पता कि यह टिप्पणी इस लेख के उद्देश्य के अनुरूप है या नहीं...
यह नज़रिए का फर्क हो सकता है,
लेकिन आखिरकार मुझे लगता है कि सबसे महत्वपूर्ण चीज़ निर्णय लेने वाले की इच्छा ही होती है।
वह जानना ही नहीं चाहता,
बस यह सुनना चाहता है कि हर हाल में हो जाएगा,
और यह भी सुनना चाहता है कि आप खुद ही संभाल लेंगे,
तो लगता है कि समझाना दरअसल निर्णयकर्ता को असुविधाजनक बात कहना ही होगा।
ps.
लगता है कि इस बात के पीछे यह पूर्वधारणा है कि निर्णयकर्ता ही सही होता है?
अगर निर्णयकर्ता = रेफरी को यह पसंद नहीं है, तो आखिरकार मुझे लगता है कि कोई भी तरीका बेकार ही होगा।
अभी समय नहीं है, इसलिए सोचा था कि फिलहाल बस तात्कालिक समस्या सुलझा लें और बाद में फिर से लिखेंगे, लेकिन ऐसी चीज़ें जमा होती-जाती हैं और आखिरकार भयानक query hell बन जाती हैं। मैंने भी ऐसी कई चीज़ें बनाई हैं। यह जानते हुए भी कि उन्हें फिर से लिखने वाला वह "बाद में" कभी नहीं आने वाला।
यह सोचें कि दूसरे teams ने भी इसे अपनाया, तो साफ है कि web development करने वाली लगभग सभी teams अपना समय बर्बाद कर रही थीं।
असल में इसे उस काम के तौर पर भी देखा जा सकता है जो किसी न किसी समय management को करना ही था, लेकिन YouTube team ने इसकी जिम्मेदारी उठाकर कर दिखाया lol
Oct 20 3:03 AM PDT हम अधिकांश प्रभावित AWS Services में रिकवरी जारी रहने को देख रहे हैं। हम पुष्टि कर सकते हैं कि US-EAST-1 पर निर्भर global services और features भी रिकवर हो चुके हैं। हम पूरी तरह समाधान की दिशा में काम जारी रखे हुए हैं और जैसे ही साझा करने के लिए अधिक जानकारी होगी, हम अपडेट देंगे.
Oct 20 2:27 AM PDT हमें रिकवरी के स्पष्ट संकेत दिखाई दे रहे हैं। अब अधिकांश requests सफल होनी चाहिए। queued requests के backlog को कम करने पर हमारा काम जारी है। हम अतिरिक्त जानकारी देते रहेंगे।
कहा जा रहा है कि अधिकांश सेवाएं बहाल हो चुकी हैं। आगे मुआवजे की योजना क्या होगी, यह जानना दिलचस्प होगा।
Docker Hub भी उसी region में outage का असर झेल रहा है, इसलिए
docker pullनहीं हो रहा और build नहीं कर पा रहे हैं.फ़िलहाल Amazon ECR Public Gallery का इस्तेमाल कर रहे हैं.
https://gallery.ecr.aws/
उम्मीद है जल्दी ठीक हो जाएगा.
उम्मीद है यह जल्दी ठीक हो जाएगा। पूरा हंगामा मचा हुआ है।
Perplexity की हिस्ट्री भी नहीं दिख रही है 🥲
आजकल ध्यान भटकाने वाले माध्यम के रूप में स्मार्टफ़ोन का सबसे ज़्यादा नाम लिया जाता है। बेशक पहली नज़र में लोगों को इस ओर ले जाने वाले application बनाने वाले ज़िम्मेदार हैं, लेकिन मेरा मानना है कि अगर इसे सही तरह से इस्तेमाल करना आता हो तो यह समस्या हल की जा सकती है.
application की notifications को डिफ़ॉल्ट रूप से सब बंद कर देना चाहिए और सिर्फ़ ज़रूरी notifications ही छोड़नी चाहिए।
बची हुई notifications को भी अहमियत के हिसाब से बाँटना चाहिए, ताकि केवल बिल्कुल ज़रूरी notifications के लिए sound/vibration चालू हो और बाकी AOD या lock screen पर भी दिखाई न दें। अगर notification आपातकालीन नहीं है, तो जब चाहें notification सूची एक साथ देखी जा सकती है।
email के मामले में भी folders बाँटकर उन्हें अपने-आप classify होने देना चाहिए और सेटिंग ऐसी होनी चाहिए कि सिर्फ़ ज़रूरी चीज़ों की ही notification आए।
सिर्फ़ इतना कर लेने से भी स्मार्टफ़ोन की वजह से ध्यान बिखरने की चिंता नहीं रहेगी। बशर्ते कि आपको हर कुछ मिनट में स्मार्टफ़ोन देखने की आदत न हो.
यह एक बेहतरीन प्रोजेक्ट है। लेकिन इसका दायरा Hugo से काफ़ी हद तक ओवरलैप करता है.
स्पष्टीकरण मांगने वाले issue के जवाब में कहा गया है कि इसमें टर्मिनल में preview, तेज़ deployment, email newsletter system, और Obsidian theme जैसी चीज़ें हैं, लेकिन यह कोई बहुत असरदार बात नहीं लगती.
Markdown render करने वाले CLI tools बहुत हैं, और newsletter के लिए भी RSS/Atom को अपने-आप publish करने वाले features काफ़ी मिल जाते हैं..
लंबी अवधि में (खासकर दोहराए जाने वाले और अकुशल) श्रम को AI और रोबोट द्वारा प्रतिस्थापित किया जाना सही है। लेकिन इसके साथ यह भी ज़रूरी होगा कि वितरण प्रणाली में बदलाव आए, ताकि सारा अतिरिक्त मूल्य केवल उत्पादकों के पास ही न चला जाए।
उम्मीद है कि यह अच्छी तरह विकसित होगा।
असल में अगर आप इसे इस तरह समझें कि software engineering में सीखी गई चीज़ों को Markdown में किया जा रहा है, तो यह आसान और व्यावहारिक है। बस requirements specification अच्छे से लिखनी आती हो, वही काफ़ी है।
पहले document driven develope या readme driven develope जैसी बातों से मिलता-जुलता लग रहा है.
https://hi.news.hada.io/topic?id=15502
मुझे नहीं पता कि यह टिप्पणी इस लेख के उद्देश्य के अनुरूप है या नहीं...
यह नज़रिए का फर्क हो सकता है,
लेकिन आखिरकार मुझे लगता है कि सबसे महत्वपूर्ण चीज़ निर्णय लेने वाले की इच्छा ही होती है।
वह जानना ही नहीं चाहता,
बस यह सुनना चाहता है कि हर हाल में हो जाएगा,
और यह भी सुनना चाहता है कि आप खुद ही संभाल लेंगे,
तो लगता है कि समझाना दरअसल निर्णयकर्ता को असुविधाजनक बात कहना ही होगा।
ps.
लगता है कि इस बात के पीछे यह पूर्वधारणा है कि निर्णयकर्ता ही सही होता है?
अगर निर्णयकर्ता = रेफरी को यह पसंद नहीं है, तो आखिरकार मुझे लगता है कि कोई भी तरीका बेकार ही होगा।
अभी समय नहीं है, इसलिए सोचा था कि फिलहाल बस तात्कालिक समस्या सुलझा लें और बाद में फिर से लिखेंगे, लेकिन ऐसी चीज़ें जमा होती-जाती हैं और आखिरकार भयानक query hell बन जाती हैं। मैंने भी ऐसी कई चीज़ें बनाई हैं। यह जानते हुए भी कि उन्हें फिर से लिखने वाला वह "बाद में" कभी नहीं आने वाला।
अब देखें तो वाकई यह एक बेहद शानदार मशीन थी।
ये ऐसी तकनीकें हैं जो पुरानी यादें ताज़ा कर देती हैं
कह...
"ज़्यादातर समस्याएँ गति और deadline के दबाव की वजह से निकाले गए अस्थायी जुगाड़ू समाधानों से पैदा होती हैं"
हाय..
उन्हें अब तक सिर्फ AI में ही देखा था, इसलिए उन्हें undergraduate छात्रों के बारे में बात करते देखना दिलचस्प है।
अच्छा, तो ऐसी योजना थी!!
हर GPU में एक-एक neural network accelerator जोड़ा गया है, यह बड़ी खासियत है, लेकिन असल में Apple जो सपोर्ट करता है वह...
यह सोचें कि दूसरे teams ने भी इसे अपनाया, तो साफ है कि web development करने वाली लगभग सभी teams अपना समय बर्बाद कर रही थीं।
असल में इसे उस काम के तौर पर भी देखा जा सकता है जो किसी न किसी समय management को करना ही था, लेकिन YouTube team ने इसकी जिम्मेदारी उठाकर कर दिखाया lol