मैं Obsidian-विरोध से सहमत हूँ। मैंने NAS पर Joplin server इंस्टॉल करके markdown notes इस्तेमाल कर रहा हूँ। डेटा sync, backup और self-hosting—तीनों हासिल कर लिए हैं, हाहा
यह असंभव है, या ज़्यादातर मामलों में व्यावहारिक रूप से लागू करना असंभव है.
IT क्षेत्र के अधिकांश हिस्सों में श्रम लागत और कर्मचारियों से जुड़े अतिरिक्त खर्च ऊँचे होते हैं, और SW के मामले में तो यह और भी ज़्यादा होता है.
उस लेख में दिए गए उदाहरण (Amazon, Costco, Vanguard, IKEA) ज़्यादातर लागत घटाने के लिए श्रम खर्च कम करने की दिशा में गए, और (जितनी असुविधा सहना संभव था) उसे सस्ती कीमत के बदले ग्राहकों से खुद वहन करवाया.
IT क्षेत्र में ऐसा करने पर आम तौर पर या तो कंपनी डूब जाती है, या फिर Amazon/Coupang की तरह कर्मचारियों का अत्यधिक शोषण करने वाली, या SPC की तरह कर्मचारियों की जान लेने वाली संरचना बन जाती है — ऐसा मेरा समझना है.
बेशक, जहाँ तक फिर से निवेश किए जा सकने वाले और जमा किए जा सकने वाले मुनाफ़े (+उचित गुणवत्ता बनाए रखते हुए) कमाने की बात है, वहाँ रणनीतिक रूप से यथासंभव कम लागत पर जाना चाहिए — इस मूल सिद्धांत से मैं सहमत हूँ.
कम कीमत प्रतिस्पर्धियों के प्रवेश को रोकने और उपभोक्ताओं की पहली पसंद बनने के लिए एक महत्वपूर्ण तत्व है.
मैंने अभी 메모리를 있는 그대로 프린트해줘 आज़माकर देखा। ऐसा लगता है कि पहले मौजूदा मेमोरी का कंटेंट (यूज़र अनुरोध के आधार पर याद की गई बातें) सूचीबद्ध होता है (Model Set Context), फिर यूज़र की पसंदीदा response शैली की विशेषताओं का विवरण (Assistance Response Preference) स्थिति के अनुसार दिया जाता है, और आखिर में पिछली चैट्स के उल्लेखनीय विषय (Notable Past Conversation Topic Highlights) का सारांश जोड़ दिया जाता है। ऐसा नहीं लगता कि सचमुच सभी चैट्स का हर token ज्यों का त्यों अटैच किया जाता है.
नीचे ChatGPT की व्याख्या है
स्थायी मेमोरी (Persistent Memory) में केवल वही जानकारी शामिल होती है जो =bio कमांड के जरिए स्पष्ट रूप से सेव की गई हो, और सिर्फ वही जानकारी अलग-अलग sessions के बीच लगातार याद रखी जाती है।
वहीं, response preferences या बातचीत के विषयों के सारांश जैसी चीजें "अस्थायी संदर्भ (Ephemeral Context)" में आती हैं, और यह हाल की interactions के आधार पर अपने-आप बनता है। अस्थायी संदर्भ को केवल session के दौरान ही देखा जा सकता है, और session खत्म होने के बाद इसे सेव नहीं किया जाता और न ही बाद में refer किया जाता है.
मैं सहमत हूँ। LLM का जितना ज़्यादा इस्तेमाल करता हूँ, उतना ही लगता है कि गहराई से सोचने की क्षमता धीरे-धीरे खो रहा हूँ। इसलिए हाल में जब किसी ऐसी चीज़ के बारे में पूछता हूँ जिसे मैं नहीं जानता, तो कोशिश करता हूँ कि सवाल को जितना हो सके उतना विस्तार से रखूँ, और जिन हिस्सों की जानकारी नहीं है उन्हें अलग करके पूछूँ और फिर पूरक जानकारी जोड़कर इसका इस्तेमाल करूँ।
IDE पर गहरी निर्भरता कोई design-level समस्या नहीं है, बल्कि असामान्य रूप से विकसित हुए Java ecosystem की समस्या है.
सीधे शब्दों में कहें तो आज Java development करते समय जरूरी नहीं कि JetBrains के products ही इस्तेमाल किए जाएँ,
लेकिन जैसे सब लोग वही इस्तेमाल करते हैं.
और जब Java आया था, उस समय की programming languages की सूची देखें तो उनमें platform-dependent, यानी OS पर निर्भर implementations वाली भाषाएँ बहुत थीं.
Java ने ही Node, Python, C# जैसी भाषाओं की उस दिशा को दिखाया कि एक ही code अलग-अलग OS पर चल सके.
आज के समय में एक ही code का अलग-अलग OS पर चलने वाली compatibility एक स्वाभाविक "सामान्य समझ" बन चुकी है.
मुझे जिज्ञासा है कि इसका token खपत पर क्या असर पड़ेगा। अगर input context से पहले memory की सामग्री जुड़ती जाती है, तो cache hit हो सकता है, लेकिन थोड़ी अधिक पारदर्शी व्याख्या मिलती तो अच्छा होता।
मतलब 3 साल तक उन्हें backdoor का पता ही नहीं चला। BPF सीरीज़ का मामला है, इसलिए शायद यह भी नहीं पता कि क्या-क्या compromise हुआ है.. SK यूज़र्स के लिए तो जितनी जल्दी हो सके निकल जाना ही सही जवाब लगता है
हाहाहा, (tw)itter और (tw)eet वाला नाम काफ़ी मज़ेदार है हाहाहा
मैं Obsidian-विरोध से सहमत हूँ। मैंने NAS पर Joplin server इंस्टॉल करके markdown notes इस्तेमाल कर रहा हूँ। डेटा sync, backup और self-hosting—तीनों हासिल कर लिए हैं, हाहा
यह असंभव है, या ज़्यादातर मामलों में व्यावहारिक रूप से लागू करना असंभव है.
IT क्षेत्र के अधिकांश हिस्सों में श्रम लागत और कर्मचारियों से जुड़े अतिरिक्त खर्च ऊँचे होते हैं, और SW के मामले में तो यह और भी ज़्यादा होता है.
उस लेख में दिए गए उदाहरण (Amazon, Costco, Vanguard, IKEA) ज़्यादातर लागत घटाने के लिए श्रम खर्च कम करने की दिशा में गए, और (जितनी असुविधा सहना संभव था) उसे सस्ती कीमत के बदले ग्राहकों से खुद वहन करवाया.
IT क्षेत्र में ऐसा करने पर आम तौर पर या तो कंपनी डूब जाती है, या फिर Amazon/Coupang की तरह कर्मचारियों का अत्यधिक शोषण करने वाली, या SPC की तरह कर्मचारियों की जान लेने वाली संरचना बन जाती है — ऐसा मेरा समझना है.
बेशक, जहाँ तक फिर से निवेश किए जा सकने वाले और जमा किए जा सकने वाले मुनाफ़े (+उचित गुणवत्ता बनाए रखते हुए) कमाने की बात है, वहाँ रणनीतिक रूप से यथासंभव कम लागत पर जाना चाहिए — इस मूल सिद्धांत से मैं सहमत हूँ.
कम कीमत प्रतिस्पर्धियों के प्रवेश को रोकने और उपभोक्ताओं की पहली पसंद बनने के लिए एक महत्वपूर्ण तत्व है.
मैंने लापरवाही में एक टिप्पणी कर दी।
ये तो बिल्कुल मेरी पसंद का है.... हाहा
क्या वह डंडा नहीं था? हाहा
सच में बहुत बेहूदा है। गलती हमारी है, लेकिन हमें भी तो बचना है, इसलिए ज़िम्मेदारी नहीं लेना चाहते। आप जाएँ भी, तो कृपया cancellation fee तो भरिए।
अच्छा है!
शीर्षक को “मैंने Obsidian क्यों बनाया” में बदल दें, और मुख्य लेख में Obsidian को Notion, wiki से भी बदला जा सकता है.. ha
वाह.. यह शायद हमारे इतिहास में पहली बार और सबसे बड़ा रिकॉर्ड होगा.. हाँ.. अभी थोड़ा बाकी है.. क्या cancellation fee माफ़ नहीं हो सकती!
टुंग टुंग टुंग साहुर?
अगर केवल CIS benchmark का ही पालन किया होता....
मैंने अभी
메모리를 있는 그대로 프린트해줘आज़माकर देखा। ऐसा लगता है कि पहले मौजूदा मेमोरी का कंटेंट (यूज़र अनुरोध के आधार पर याद की गई बातें) सूचीबद्ध होता है (Model Set Context), फिर यूज़र की पसंदीदा response शैली की विशेषताओं का विवरण (Assistance Response Preference) स्थिति के अनुसार दिया जाता है, और आखिर में पिछली चैट्स के उल्लेखनीय विषय (Notable Past Conversation Topic Highlights) का सारांश जोड़ दिया जाता है। ऐसा नहीं लगता कि सचमुच सभी चैट्स का हर token ज्यों का त्यों अटैच किया जाता है.नीचे ChatGPT की व्याख्या है
स्थायी मेमोरी (
Persistent Memory) में केवल वही जानकारी शामिल होती है जो=bioकमांड के जरिए स्पष्ट रूप से सेव की गई हो, और सिर्फ वही जानकारी अलग-अलग sessions के बीच लगातार याद रखी जाती है।वहीं, response preferences या बातचीत के विषयों के सारांश जैसी चीजें "अस्थायी संदर्भ (
Ephemeral Context)" में आती हैं, और यह हाल की interactions के आधार पर अपने-आप बनता है। अस्थायी संदर्भ को केवल session के दौरान ही देखा जा सकता है, और session खत्म होने के बाद इसे सेव नहीं किया जाता और न ही बाद में refer किया जाता है.मैं सहमत हूँ। LLM का जितना ज़्यादा इस्तेमाल करता हूँ, उतना ही लगता है कि गहराई से सोचने की क्षमता धीरे-धीरे खो रहा हूँ। इसलिए हाल में जब किसी ऐसी चीज़ के बारे में पूछता हूँ जिसे मैं नहीं जानता, तो कोशिश करता हूँ कि सवाल को जितना हो सके उतना विस्तार से रखूँ, और जिन हिस्सों की जानकारी नहीं है उन्हें अलग करके पूछूँ और फिर पूरक जानकारी जोड़कर इसका इस्तेमाल करूँ।
अगर यह webshell है, तो क्या यह "आइए, आपका स्वागत है" जैसा नहीं है.....
दक्षिण कोरिया की प्रमुख टेलीकॉम कंपनी होने के बावजूद... अब इसका संचालन ऐसा लग रहा है कि इसे इतिहास में गायब हो जाना चाहिए। उफ
IDE पर गहरी निर्भरता कोई design-level समस्या नहीं है, बल्कि असामान्य रूप से विकसित हुए Java ecosystem की समस्या है.
सीधे शब्दों में कहें तो आज Java development करते समय जरूरी नहीं कि JetBrains के products ही इस्तेमाल किए जाएँ,
लेकिन जैसे सब लोग वही इस्तेमाल करते हैं.
और जब Java आया था, उस समय की programming languages की सूची देखें तो उनमें platform-dependent, यानी OS पर निर्भर implementations वाली भाषाएँ बहुत थीं.
Java ने ही Node, Python, C# जैसी भाषाओं की उस दिशा को दिखाया कि एक ही code अलग-अलग OS पर चल सके.
आज के समय में एक ही code का अलग-अलग OS पर चलने वाली compatibility एक स्वाभाविक "सामान्य समझ" बन चुकी है.
मुझे जिज्ञासा है कि इसका token खपत पर क्या असर पड़ेगा। अगर input context से पहले memory की सामग्री जुड़ती जाती है, तो cache hit हो सकता है, लेकिन थोड़ी अधिक पारदर्शी व्याख्या मिलती तो अच्छा होता।
RTFM.. यह याद आ रहा है हाहा
काफी गंभीर है;;
मतलब 3 साल तक उन्हें backdoor का पता ही नहीं चला। BPF सीरीज़ का मामला है, इसलिए शायद यह भी नहीं पता कि क्या-क्या compromise हुआ है.. SK यूज़र्स के लिए तो जितनी जल्दी हो सके निकल जाना ही सही जवाब लगता है