मुझे कंपाइलर से नफ़रत है

पुनरुत्पादनीय बिल्ड्स और कंपाइलर की नियतात्मकता

• इस बात पर काफ़ी असहमति है कि पुनरुत्पादनीय बिल्ड्स कितने महत्वपूर्ण हैं।
  • समर्थक पक्ष: डिस्ट्रो बाइनरीज़ (जैसे xz) की सत्यापन, GPL अनुपालन जाँच, सैन्य या उच्च-आश्वासन वाले उपयोगकर्ताओं का समर्थन जो री-कंपाइल करके हैश तुलना करते हैं, और ऑडिटरों को यह प्रमाण देने के लिए कि शिप किया गया बाइनरी समीक्षा किए गए कोड से मेल खाता है, इसकी ज़रूरत बताता है।
  • संशयवादी पक्ष: इन्हें अधिकतर सैद्धांतिक मानता है; बिट-टू-बिट समान आउटपुट की तुलना में signatures और CI traceability को तरजीह देता है; तर्क देता है कि जिन उपयोगकर्ताओं को परवाह है, उन्हें source से खुद build करना चाहिए।
• ठोस समस्याएँ:
  • पॉइंटर-आधारित या अपरिभाषित iteration order वाली data structures (जैसे LLVM का DenseMap) और ASLR के कारण आंतरिक layout प्रभावित होने से compiler का गैर-नियतात्मक व्यवहार; सुझाए गए fixes में deterministic containers (MapVector) का उपयोग और इसे compiler bugs की तरह扱ना शामिल है।
  • timestamps और build-time macros जैसे __DATE__/__TIME__ को reproducibility तोड़ने के “आसान” तरीक़े के रूप में उद्धृत किया गया है। इस पर बहस है कि क्या यह एक स्पष्ट और जानबूझकर किया गया tradeoff है या एक आसान accidental footgun; कुछ लोगों का तर्क है कि ऐसे macros का compilers में स्थान नहीं होना चाहिए।
• Nix/Guix:
  • hermetic build environments के लिए प्रशंसा मिली है (जैसे SOURCE_DATE_EPOCH से समय स्थिर करना, input hashing)।
  • अन्य लोग नोट करते हैं कि ये compiler bugs या concurrency-निर्भर non-determinism को हल नहीं करते।

LLMs, बाइनरीज़, और कंपाइलर

• चर्चा की एक पंक्ति सुझाव देती है कि LLMs को सीधे binaries पर train करके machine code generate किया जाए।
• अधिकतर प्रतिक्रियाएँ संशयपूर्ण हैं:
  • बाइनरी में छोटे perturbations executables को तोड़ देते हैं; कोई “plausible” binary नहीं होती।
  • LLMs counting और fine-grained precision में संघर्ष करते हैं (जैसे exact jump offsets), भले ही वे high-level या अस्पष्ट कार्यों में अच्छे हों।
  • कोई भी गंभीर harness अंततः compiler/assembler जैसी संरचना फिर से ला देगा।
• “कठिन” बनाम “आसान” कार्यों पर इंसानों और LLMs के लिए एक अलग बहस, और Moravec’s paradox की प्रासंगिकता पर चर्चा।

निम्न-स्तरीय बनाम उच्च-स्तरीय परिवेश

• एक दृष्टिकोण: low-level काम अत्यधिक environment-specific होता है (hardware, CPU generations, vendor protocols), hidden assumptions से भरा; इसलिए LLMs वहाँ high-level “wrapping” की तुलना में अधिक संघर्ष करते हैं।
• प्रतिवाद: सरल, dependency-light procedural code fast-churning web frameworks की तुलना में अपेक्षाकृत स्थिर होता है; इस पर बहस कि “low-level” क्या माना जाए (C + OS libs बनाम GUI/web frameworks)।

Anubis proof-of-work protection

• आलोचक client-side PoW challenges की तुलना malware या crypto miners से करते हैं: व्यर्थ ऊर्जा, accessibility संबंधी चिंताएँ, और पर्याप्त compute वाले बड़े AI companies के खिलाफ सीमित deterrence।
• समर्थक इसे abusive scrapers को throttling करने और hosting costs को संभालने योग्य रखने के लिए आवश्यक “nuclear option” के रूप में प्रस्तुत करते हैं, जिसमें challenge difficulty client signals (residential IP, behavior) के अनुसार अनुकूलित होती है।
• कुछ लोग सुझाव देते हैं कि PoW से “useful work” कराया जाए (crypto, protein folding), लेकिन अन्य चिंता जताते हैं कि इसे botnet-जैसा देखा जाएगा; तकनीकी बाधाएँ (data size, coordination) भी नोट की गई हैं।