मैं भी non-smoker हूँ, इसलिए मुझे पता नहीं था, लेकिन हाल ही में हमारे मोहल्ले में खुले एक unmanned cafe में disposable e-cigarette vending machine देखकर मुझे यह बात पता चली। नीचे के Hacker News कमेंट्स में भी आधे लोग बेहूदा resource waste की बात कर रहे हैं. हा हा

2000 के दशक के आखिर में वाहन navigation software कंपनी में काम करते हुए route search module डेवलप करने की यादें(?) ताज़ा हो गईं।
Dijkstra navigation route search के लिए बहुत धीमा था, इसलिए उसे इस्तेमाल नहीं करते थे और heuristic से बेहतर बनाया गया वर्जन A*(A Star) search इस्तेमाल करते थे। खोजने पर पता चला कि A* SSSP नहीं बल्कि SPSP(Single-Pair Shortest Path) algorithm है।

इसे बनाकर देखने वाले के नज़रिए से कहूँ तो, personalization के लिए ज़्यादा होने पर 2GB से भी अधिक जानकारी की मात्रा चाहिए होती है।

format conversion के लिए markitdown सुविधाजनक है, लेकिन PDF के लिए इसे बिल्कुल इस्तेमाल नहीं करना चाहिए, हाँ।

दस्तावेज़ extraction में Gemini जैसे multimodal LLM का उपयोग करने वाले कई तरीके पहले से मौजूद हैं, और benchmark में भी इनके नतीजे काफ़ी अच्छे आते हैं। बस लागत ही समस्या है।

docling जैसी चीज़ भी अच्छी है।

लगता है कि इसकी फ़ीचर्स और approach Atlas जैसी ही हैं: https://atlasgo.io/

मैं इन तीन प्रमुख जालों से बहुत सहमत हूँ। सिर्फ़ एक gatekeeper होने पर भी कई तरह की बुरी समस्याएँ पैदा हो जाती हैं।

लो-लेवल... कहना भी मुश्किल है... फ़ॉर्म implement करने के लिए सिर्फ़ HTML input टैग इस्तेमाल करने से काम चल सकता है, लेकिन state, jsx, uncontrolled/controlled components जैसी चीज़ें बेवजह बहुत ज़्यादा जाननी पड़ती हैं और बहुत सारा कोड भी लिखना पड़ता है, इसलिए शायद यही बातें मूल लेख की प्रेरणा बनी होंगी।

मैं धूम्रपान नहीं करता, इसलिए पहले समझ नहीं आया कि बात क्या है, लेकिन आपका कहना है कि एक बार इस्तेमाल होने वाली चीज़ होने के बावजूद इसमें बहुत ज़्यादा संसाधनों का उपयोग होता है।

karma -47 की शान lol

ऐसा लगता है जैसे सिर्फ इसलिए कहा जा रहा है कि पुराना तरीका खत्म हो गया, क्योंकि एक नया तरीका आ गया है.
क्या सच में पुराने तरीके का अब इस्तेमाल नहीं किया जा सकता और सिर्फ नया तरीका ही इस्तेमाल करना होगा?

मैं इस कॉन्सेप्ट से काफ़ी सहमत था, इसलिए वीकेंड पर एक नए प्रोजेक्ट में इसका थोड़ा परीक्षण करके देखा, लेकिन यह उम्मीद के मुताबिक़ उतना अच्छा काम नहीं कर पाया। लगता है कि अभी इसमें काफ़ी सुधार की ज़रूरत है। फ़िलहाल इसकी मोटे तौर पर काम करने की प्रक्रिया, जैसा कि कई बार बताया जा चुका है, इस प्रकार है:
संविधान लिखना → स्पेक लिखना → टास्क लिखना → इम्प्लीमेंटेशन

समस्या यह है कि

• constitution.md फ़ाइल "कैसे डेवलप करना है" के बारे में मुख्य गाइड है, लेकिन इसमें "यह ऐप आखिरकार क्या बनेगा" शामिल नहीं है
• spec.md किसी एक फीचर को समझाने वाला दस्तावेज़ है
• "यह ऐप क्या है" इस बारे में कोई मास्टर दस्तावेज़ नहीं है
• GitHub पर चल रही चर्चाएँ पढ़कर लगा कि specs की chain ही अंततः source of truth बन जाएगी — ऐसा लगता है। थोड़ा अजीब लगा, लेकिन मोटे तौर पर समझा जा सकता है।
• /specify और /tasaks कमांड के ज़रिए बहुत सारे दस्तावेज़ output के रूप में बनते हैं (जो मैं चाहता था), लेकिन शायद इसी वजह से context बहुत जल्दी ख़र्च होता है (मैं Claude Code इस्तेमाल कर रहा हूँ)
• एक बार इम्प्लीमेंटेशन शुरू हो जाए तो Spec Kit से थोड़ी दूरी बन जाती है, और फिर सामान्य तौर पर Claude Code के साथ बातचीत करते हुए इम्प्लीमेंटेशन पूरा होता है
• context पूरी तरह ख़त्म हो जाए और compaction हो जाए या नया session शुरू किया जाए, तो Spec Kit द्वारा बनाए गए दस्तावेज़ों का अस्तित्व ही भूल जाता है
• tasks.md में परिभाषित कामों को करते-करते पहले ठीक से बनाई गई चीज़ें भी overwrite हो जाती हैं, और बग ठीक करते समय नए फीचर भी बन जाते हैं, जिससे tasks.md से दूरी बढ़ती जाती है। मुझे समझ नहीं आता कि tasks.md को स्थायी रूप से सहेजकर रखने का क्या मतलब है।

फ़िलहाल मैंने जो निष्कर्ष निकाला है, वह इस प्रकार है:

• अगर शुरुआती सोच से अलग नतीजा आए तब भी पहले स्पेक को पूरा करना चाहिए, और फिर नया स्पेक बनाकर उसे धीरे-धीरे सुधारना चाहिए
• शुरुआती स्पेक का बड़ा होना लगभग तय है, इसलिए ऐप के फीचर्स को बिल्कुल समझाने के बजाय सिर्फ़ boilerplate बनाना बेहतर होगा
• PoC स्तर पर बनाते समय Spec Kit का इस्तेमाल न करना ही बेहतर होगा

हाहाहाहाहाहाहा

मैं इससे बहुत सहमत हूँ। चाहे वह कितना भी अच्छा हो, दखल देने वाला होना असुविधाजनक है। बेहतर यह है कि वह जैसे मौजूद ही न हो, लेकिन जब ज़रूरत लगे तब सामने आकर मदद करे; यहाँ असली बात शायद यह होगी कि वह स्थिति का कितना उचित आकलन कर पाता है। इंसानों में भी कुछ लोग इसमें अच्छे होते हैं और कुछ नहीं, इसलिए अगर AI इसे पार कर सके तो लगता है कि एक क्रांति हो सकती है।

Vulkan के बारे में सटीक रूप से कहें तो, सही बात यह है कि 'Pi 5 के iGPU द्वारा समर्थित Vulkan API को अभी llama.cpp में सपोर्ट नहीं किया गया है'। अगर इसका सपोर्ट होता, तो प्रदर्शन कितना मिलता, यह भी जानने की जिज्ञासा होती।

docling भी अच्छा है

वाह! Ultrasonic cutter!

markitdown, PDF parsing के लिए https://github.com/pdfminer/pdfminer.six का उपयोग करता है, और text या embedded images को फ़ाइल से उसी रूप में extract करता है। OCR वगैरह की बात सुनकर ही सिर घूमने लगता है...

यह gpt-oss से ज़्यादा महंगा और धीमा लगता है, तो लोग इसे इतना ज़्यादा क्यों इस्तेमाल कर रहे हैं, यह जानने की उत्सुकता है..

जिन लोगों को Korean prompts चाहिए, उनके लिए यहाँ Korean में अनूदित prompts हैं। बस क्लिक करते ही ये सीधे ChatGPT और Claude में इनपुट हो जाते हैं。

https://gongbuhow.com/posts/chatgpt-students-100-use-cases/

जब 5 सेकंड के एक-दो ads चलते थे, तो सह-अस्तित्व वाली भावना से मैं उन्हें पूरा देख लेता था, लेकिन जब न खत्म होने वाले लगातार ads और वीडियो के बीच-बीच में ads ठूंसना हद पार करने लगा, तो मैंने तुरंत ad blocker इंस्टॉल कर लिया, हाहा