अलविदा, अब तक के सभी Bikeshed के लिए धन्यवाद

 (queue.acm.org)
1 पॉइंट द्वारा GN⁺ 1 일 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • FOSS के भविष्य को बदलने वाले दो कारकों के रूप में LLM-आधारित code review और age verification को चिन्हित किया गया है, और खास तौर पर यह अनुमान है कि age verification, FOSS को उसके मौजूदा रूप में समाप्त करने का कारण बन सकता है
  • LLM code review ऐसे search space की और अधिक चौड़ाई और गहराई से जांच कर सकता है जिसे इंसान देख पाना कठिन है, लेकिन शुरुआती बड़ी सफलताओं के बाद इसकी उपयोगिता घट सकती है, इसलिए इसकी आर्थिक स्थिरता अनिश्चित है
  • जब online crime और child protection से निपटने के लिए राज्य age verification की मांग करेंगे, तो ऐसे cryptographically proven software और computing platform की आवश्यकता होगी जिन्हें उपयोगकर्ता बदल न सके
  • EU की digital sovereignty और जवाबदेही की मांग, व्यक्तिगत maintainers और disclaimer पर निर्भर FOSS संरचना से टकराती है, और जैसे ही राजस्व उत्पन्न होता है, Cyber Resilience Act की FOSS exception भी समाप्त हो जाती है
  • प्रभावशाली FOSS projects अब व्यक्तिगत आजीवन benevolent dictator (BDFL) के बजाय कंपनियों या governance organizations द्वारा नियुक्त committees के जरिए चलाए जा सकते हैं, और उपयोगकर्ताओं को सिर्फ source पढ़ने या बिना बदलाव के build करने की अनुमति मिल सकती है

आखिरी Bikeshed और भविष्य के दो चर

  • लगभग 20 साल पहले flash memory पर लेख लिखने के अनुरोध से शुरू होकर, लगभग साल में एक बार आने वाला Bikeshed column शुरू हुआ
  • लेखक कहता है कि वह आत्मविश्वास से भरा बुजुर्ग विशेषज्ञ नहीं बनना चाहता, इसलिए column यहीं समाप्त करता है और आशा करता है कि दूर के भविष्य को लेकर उसका अनुमान पूरी तरह गलत निकले
  • वह वर्तमान FOSS पर बड़ा असर डालने वाले मुद्दों के रूप में LLM-assisted code review और age verification को चिन्हित करता है

LLM code review की उपलब्धियां और सीमाएं

  • विभिन्न code quality tools के उपयोग के अनुभव में बार-बार एक ही पैटर्न दिखाई दिया
    • पहले 1~2 दिनों में बड़ी संख्या में समस्याएं मिलती हैं
    • 3~5 दिनों में कुछ निश्चित bugs और तकनीकी रूप से bugs लेकिन बहुत गंभीर नहीं होने वाले मुद्दे सामने आते हैं
    • दूसरे हफ्ते से नई उपलब्धियां लगभग खत्म हो जाती हैं
  • यह पैटर्न 1984 के Zilog Zeus manual में lint(1) देखने के समय से लेकर हाल में Clang static analysis इस्तेमाल करने तक जारी रहा
  • इसके आधार पर लेखक मानता है कि LLM tools जिन सबसे खराब software bugs को ढूंढ सकते हैं, उनमें से आधे से ज्यादा शायद पहले ही सार्वजनिक हो चुके हैं
  • यह अनुमान इस बात से भी मजबूत होता है कि AI industry निवेश का उत्साह बनाए रखने के लिए बड़ी सफलताओं को जितना जल्दी हो सके सार्वजनिक करना चाहती है
  • वह सुझाव देता है कि अगर किसी model को nuclear power plant की पूरी design और as-built documentation दी जाए, तो यह human engineering systems की जटिलता को संभालने की उसकी सीमाओं की परीक्षा भी होगी और बड़ा ध्यान भी खींचेगा

शतरंज जैसी bug खोज

  • LLM tools की bug खोज computer chess जैसी है
    • इंसान समय और ऊर्जा बचाने के लिए अधिक संभावना वाले रास्तों को probabilistic और heuristic तरीके से खोजते हैं
    • LLM इंसानों की तुलना में search tree को और अधिक चौड़ाई और गहराई से जांच सकते हैं
  • cyber attack और defense मूल रूप से chess जैसे खेल हैं, और भविष्य में जिन programs पर हम अपनी जान भरोसे में छोड़ेंगे, उन्हें लिखने के लिए बेहतर tools की जरूरत होगी
  • असली सवाल यह है कि क्या LLM code review, investment bubble के बाहर भी आर्थिक रूप से टिकाऊ हो सकता है

model training cost और replication economics

  • model का अधिकांश काम और खर्च training phase में पहले ही लगाया जाता है, लेकिन उसका परिणाम यानी model weights इतने छोटे होते हैं कि आधुनिक portable storage device में समा जाएं
  • मुनाफा कमाने के लिए वही weights लाखों बार बेचने पड़ते हैं
  • यह कुछ वैसा है जैसे set, actors, costumes, special effects और marketing पर लाखों डॉलर खर्च करके ऐसा 4K video बनाया जाए जो छोटे storage device में आ जाए, और फिर उससे किशोरों की pocket money के छोटे हिस्सों के बराबर इकाइयों में कमाई की जाए; यह film और video industry जैसा मॉडल है
  • Hollywood ने copyright protection के जरिए इस ढांचे को कुछ हद तक बनाए रखा, लेकिन LLM industry ने copyright infringement मामलों में बार-बार fair use का सहारा लिया है, इसलिए उसके लिए वही सुरक्षा हासिल करना मुश्किल हो सकता है
  • अगर investment bubble फूट जाए और उपलब्धियां धीरे-धीरे कम होने लगें, तो अगली पीढ़ी के models की training cost कौन उठाएगा, यह स्पष्ट नहीं है

encryption के बाद राज्य और anonymity का टकराव

  • शुरुआती store-and-forward communication और उससे पैदा हुए open source पर प्रभावशाली संस्थाओं ने ज्यादा ध्यान नहीं दिया था
  • जब monetization संभव हुआ, तो development funding आई और यह आगे बढ़कर online digital communication जैसे बड़े बाजार तक पहुंचा
  • इस प्रक्रिया में FOSS ने तकनीकी प्रगति और revenue generation, दोनों को तेज किया
  • Edward Snowden के खुलासों के बाद tech industry ने निगरानी रोकने के लिए व्यापक end-to-end encryption को आगे बढ़ाया
  • नतीजतन अपराधियों के लिए अपने online traces छिपाना आसान हो गया, और अक्षम अपराधियों या बहुत बड़े आर्थिक नुकसान वाले मामलों को छोड़कर prosecution कठिन हो गया
  • लेखक मानता है कि बहुत से digital crimes की रिपोर्ट ही नहीं होती, क्योंकि लोगों को लगता है कि पुलिस कुछ कर ही नहीं पाएगी
  • उसके अनुसार encryption ने राज्यों को बिना निकास वाली स्थिति में धकेल दिया, और अब राज्य उस स्थिति से बाहर निकलने की कोशिश कर रहे हैं

age verification और privacy का संकुचन

  • privacy advocates अनिवार्य age verification का विरोध करते हुए कहते हैं कि इससे पूरे internet पर व्यापक identity verification लागू हो सकता है, और वे सरकार की नागरिक चिंताओं को सिर्फ “बच्चों के बारे में सोचो” वाली दलील मानकर खारिज करते हैं
  • लेखक का आकलन है कि पूर्ण privacy अधिकार की मांग करने वाली women technologists बहुत कम हैं
  • वह उम्मीद करता है कि उसकी बेटी को पहला phone मिलने पर माता-पिता को online जोखिमों पर अलग से बातचीत करने की जरूरत न पड़े, क्योंकि internet anonymity कम हो जाएगी; और बेटी के पिता के रूप में वह इसका समर्थन करता है
  • उसका कहना है कि protocols को rule-of-law states के साथ न्यूनतम संगतता के हिसाब से design किया जा सकता था, लेकिन समझौते को विश्वासघात मानने के कारण अब जरूरत से ज्यादा privacy खोनी पड़ सकती है

संशोधित किए जा सकने वाले FOSS और age verification का टकराव

  • अगर source code बदला और फिर से compile किया जा सकता है, तो उपयोगकर्ता age verification feature को हटा सकते हैं
  • इसे रोकने का एकमात्र तरीका लेखक cryptographically proven software integrity को मानता है
    • किसी को औपचारिक रूप से यह गारंटी देनी होगी कि operating system भरोसेमंद है
    • अगर उपयोगकर्ता operating system को बदलकर फिर से compile कर सके, तो कोई भी ऐसी गारंटी देने को तैयार नहीं होगा
  • internet धीरे-धीरे ऐसे हिस्सों में बंटता जा रहा है जहां किसी भी browser, device या software से पहुंच संभव होने वाला क्षेत्र छोटा होता जा रहा है
  • अधिक से अधिक services सिर्फ attested computing platform पर ही उपलब्ध हो रही हैं, और उपयोगकर्ता source code देख तो सकते हैं, लेकिन शायद उसे बदल नहीं सकेंगे

EU digital sovereignty और जवाबदेही

  • पिछले कई दशकों के neoliberalism और globalization के दौरान अमेरिकी tech industry ने social media सहित यूरोप के अधिकांश IT market पर कब्जा कर लिया
  • EU, उसके member states और कंपनियां इसे गंभीर गलती मानती हैं और digital sovereignty वापस पाना चाहती हैं
  • अगर यूरोप के अपने online monopoly firms होते, तो कानून बदलकर जवाब दिया जा सकता था, लेकिन Google, Apple, Oracle, Microsoft, Facebook और Twitter के यूरोपीय समकक्ष मौजूद नहीं हैं
  • यूरोपीय CIOs को FOSS source code मिल भी जाए, तो उनके पास न कोई supplier है जिसके साथ contract negotiate किया जा सके, न कोई counterpart जिस पर signature हो सके
  • मौजूदा organizational culture समस्या सुलझाने से ज्यादा जिम्मेदारी किसी और पर डालना पसंद करती है, लेकिन digital sovereignty जैसे मुद्दे, जिनमें अंतिम जवाबदेही वाले पक्ष की जरूरत होती है, उसके लिए यह उपयुक्त नहीं है
  • FOSS licenses में आम तौर पर शामिल no-warranty और indemnity disclaimer के कारण, जवाबदेही के मौजूदा मॉडल को FOSS पर लागू करना भी कठिन है
  • “Microsoft खरीदने पर किसी की नौकरी नहीं जाती” जैसे माहौल में बड़े हुए decision-makers के लिए यह बदलाव परिचित नहीं है

Cyber Resilience Act की FOSS exception

  • EU, FOSS को digital sovereignty की एकमात्र व्यावहारिक आशा मानते हुए, हालिया कानून Cyber Resilience Act में बड़ा exception देता है
  • लेकिन जैसे ही FOSS से revenue कमाया जाता है, यह exception खत्म हो जाती है
  • लेखक का अनुमान है कि आने वाले 10 वर्षों में EU में FOSS से पर्याप्त लाभ उत्पन्न होगा, इसलिए commercialization मौजूदा रूप वाले FOSS के अंत को और तेज कर सकता है

व्यक्तिगत maintainer संरचना की स्थिरता

  • बहुत-सा FOSS एक ही व्यक्ति की इच्छा पर टिकता है, और वह व्यक्ति यह न जानता हो या परवाह न करता हो कि उसके project के ऊपर कितनी infrastructure खड़ी हो चुकी है
  • maintainer burnout पहले से मौजूद है, और चूंकि FOSS bell-bottoms या flower power जैसी पीढ़ीगत घटना के अधिक करीब लगता है, maintainers की मृत्यु भी अधिक बार होने वाली समस्या बन सकती है
  • मौजूदा पीढ़ी की सद्भावना पर निर्भर maintainers के बाद उत्तराधिकारियों को आकर्षित करना पहले ही मुश्किल है
  • जब maintainer को भुगतान नहीं मिलता, लेकिन नए “FOSS steward” और “FOSS manufacturer” उसी software से revenue कमाते हैं, तो उत्तराधिकारी खोजना और भी असंभव हो जाता है
  • लेखक का अनुमान है कि आजीवन benevolent dictator के दौर का अंत होगा, और प्रभावशाली projects को FOSS governance organizations या कंपनियों द्वारा नियुक्त committees बनाए रखेंगी

बाड़े के भीतर जाता FOSS

  • अपराध को सक्षम बनाने वाली पूर्ण privacy का जवाब देने के लिए attested computing platforms की जरूरत होगी
  • EU digital sovereignty की बुनियाद में भी “कोई व्यक्तिगत व्यक्ति” नहीं, बल्कि कानूनी अस्तित्व वाली governance entity की जरूरत होगी
  • पिछली पीढ़ियों का वह FOSS क्षेत्र, जहां लोग स्वतंत्र रूप से प्रयोग करते थे, भविष्य में करदाताओं के खर्च की सीमा के भीतर regulated, safety-approved और commercial traffic से अलग किए गए controlled environment में बदल सकता है
  • मौजूदा FOSS की विशेषताओं में शायद सिर्फ इतना बचे कि उपयोगकर्ता source code पढ़ सकें
  • reproducible builds के फैलने पर source को सीधे compile करना संभव हो सकता है, लेकिन शायद बदलाव न करने की शर्त के साथ

walled app store model

  • FOSS में जवाबदेही लाने का सबसे कम प्रतिरोध वाला रास्ता शायद walled app store model हो सकता है
    • केवल cryptographically authenticated kernel ही age verification और web access के लिए जरूरी कानूनी attestation देगा
    • FOSS governance organization द्वारा स्वीकृत app store से डाउनलोड किए गए बिना बदले programs ही browser sandbox के बाहर चल सकेंगे
  • 40 साल से अधिक पुराने एक दोस्त के नए laptop पर Ubuntu install करने के अनुभव में लेखक को ऐसे भविष्य की झलक मिली
  • वह मानता है कि Ubuntu ने FOSS के प्रसार में योगदान दिया है, लेकिन installation process उसे उस भविष्य से बहुत ज्यादा मिलता-जुलता लगा जिससे वह चिंतित है, और वह चाहता है कि उसकी यह भविष्यवाणी गलत साबित हो

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 16 시간 전
Hacker News की राय

  • वापस पलटे जा सकने वाले फ़ैसले ऐसे हों तो बेहतर है कि जो व्यक्ति स्वेच्छा से जिम्मेदारी ले, उसे अपनी समझ से करने दिया जाए। ऊँची तनख्वाह पाने वाले लोग छोटी बातों पर मीटिंग करके कुल मिलाकर 5,000~10,000 डॉलर की मानव-लागत जला दें, उससे सस्ता और विकास के लिए बेहतर यह है कि कोई mid-level engineer उसे दो-तीन बार फिर से implement कर ले
    कोड का interface सबके लिए महत्वपूर्ण होता है, लेकिन उसकी internal implementation मुख्य रूप से उन bus factor लोगों के लिए महत्वपूर्ण होती है जो उस कोड की जिम्मेदारी उठाएँगे। ऐसा भी हुआ है कि वास्तविक जिम्मेदार व्यक्ति कम प्रभाव वाले तरीके को चाहता था, फिर भी समूह ने ज्यादा चमकदार लेकिन नाज़ुक design चुन लिया

    • जो टीमें अंतहीन तुलना में मज़ा लेती हैं, वे किसी नए feature के लिए इस्तेमाल होने वाली हर open source library और framework से prototype बनाती हैं, report और discussion भी पूरा करती हैं, और उसके बाद ही असली implementation शुरू करती हैं। इससे बेहतर है कि जो एक विकल्प सहज रूप से सही लगे उसे चुनो; अगर prototype काम करता है तो उसी को implementation मान लो, और alternatives सिर्फ़ तब देखो जब दोबारा विचार करने की पर्याप्त वजह हो
      अगर फ़ैसला करना इसलिए कठिन है क्योंकि विकल्पों में फ़र्क बहुत छोटा है, तो उसकी अहमियत भी कम है, यानी पासा फेंककर तय कर दो तो भी चलेगा
    • जब बहुत सक्षम लोग कागज़ पर लंबे समय तक design किया हुआ समाधान वास्तविक दुनिया में काम नहीं करता, फिर भी गलती मानने के बजाय उसे ज़बरदस्ती बचाने के लिए sunk cost और झोंकते रहते हैं, तब हालात और खराब हो जाते हैं
    • कुछ enterprise architecture संभालने वालों का तो मानो यही मुख्य काम लगता है कि उनका व्यावहारिक अनुभव 10 साल पहले रुक गया, और सिर्फ़ इसलिए कि उन्होंने कभी Kafka को किसी की queue समस्या सुलझाते देखा था, वे synchronous calls सहित हर API को Kafka पर चढ़वा देते हैं
    • अगर design कम सक्षम व्यक्ति को दे दिया जाए, तो पहला और सबसे खराब version हमेशा के लिए रह सकता है। जिस कंपनी से मैं जा रहा हूँ, वहाँ हर बार समस्या दिखने पर code लिखने वाले व्यक्ति को design भी पूरा का पूरा दे दिया जाता था, और QA को release से 1~2 हफ़्ते पहले तैयार build मिलता था, जिसके बाद वे सिर्फ़ सतही bugs ही report कर पाते थे
      नतीजा यह हुआ कि codebase और मनोबल दोनों साथ में टूट गए, और गलत design के ऊपर budget की कमी और process की अनुपस्थिति से और गलतियाँ जमा होती गईं, अब उन्हें ठीक करना भी मुश्किल है। niche market में उत्पाद की मौलिकता और उसे खरीदने वाली बड़ी कंपनी के support की वजह से product किसी तरह चल रहा है, लेकिन उस बड़ी कंपनी की निर्भरता भी कम है, इसलिए वह पूरी audit पर समय नहीं लगाती
    • Amazon का two-way door concept यही है। अगर आप पहचान लें कि कोई विकल्प अपेक्षाकृत कम लागत में लिया, वापस लिया, और फिर दोबारा लिया जा सकता है, तो आप सचमुच जोखिम भरे फ़ैसलों पर ध्यान केंद्रित कर सकते हैं

  • PHK ने कई कामों के साथ MD5crypt password hash algorithm($1$…) भी बनाया। यह bcrypt(1999), scrypt(2009), SHA2crypt(2016) से पहले, 1994 में commit हुआ था
    https://svnweb.freebsd.org/base/head/lib/libcrypt/crypt.c?re...
    https://github.com/freebsd/freebsd-src/commit/3b2b7f71deba2a...
    https://phk.freebsd.dk/sagas/md5crypt/
    https://en.wikipedia.org/wiki/Poul-Henning_Kamp

    • इसका मतलब यह नहीं कि उन्होंने खुद MD5 बनाया था। MD5 Ron Rivest ने 1991 में बनाया था, और मैंने उसे पहली बार 1995~1996 में देखा; तब से backend web काम में उसे किसी जादुई tool की तरह मानकर हर जगह इस्तेमाल करता रहा हूँ
    • PHK के पास इस विषय पर बोलने के लिए कैसी योग्यता है, इस पर मुझे संदेह है

  • पहली बार पढ़ते समय मुझे गुस्सा आया था, लेकिन कई बार दोबारा पढ़ने पर मेरी राय काफ़ी बदल गई। लेखक वास्तव में क्या कहना चाहता है, यह समझने के लिए इसे कई बार पढ़ना सार्थक है

    • encryption में समझौते की कोई वास्तविक मध्य-भूमि नहीं होती। या तो आप हर electronic device पर सिर्फ़ approved software चलाना अनिवार्य करें, या आसान encrypted messaging की अनुमति दें; थोड़ी-सी भी कमजोरी सबकी privacy को नुकसान पहुँचाती है, लेकिन अपराधियों का इस्तेमाल रोकना है तो encryption को पूरी तरह प्रतिबंधित करना पड़ेगा
      लेखक को लगता है कि थोड़ा-बहुत समझौता करके अदालतों को शांत किया जा सकता है, लेकिन उसने प्रेरणा को गलत समझा है। असली कानून-प्रस्ताव बड़ी tech कंपनियों की lobbying से आते हैं, जो जिम्मेदारी से बचना चाहती हैं और user data बेचकर मुनाफ़ा कमाती हैं: https://github.com/upper-up/meta-lobbying-and-other-findings
    • लेखक कुछ बड़ी कंपनियों के किए की जिम्मेदारी FOSS और तथाकथित tech elite पर भी डालता है, और जिन regulations के लिए वे कंपनियाँ lobbying करती हैं, उन्हें मानो हमारी सज़ा की तरह स्वीकार करता है। वह मानता भी है कि यह असली विधायी कारण नहीं है, फिर भी इसे बच्चों की सुरक्षा के लिए आवश्यक बुराई बताता है, और privacy को महत्व देने वाले लोगों को या तो बेहद अल्पसंख्यक या काल्पनिक मानता है; यह स्वीकार करना कठिन है
    • मुझे यह लेखन शैली पसंद नहीं, जिसमें ऐसे तर्क फेंके जाते हैं जिन पर लेखक खुद भी सच में विश्वास नहीं करता और जानता है कि वे दुर्भावनापूर्ण हैं, फिर भी एक दीन-सी “साबित करके दिखाओ कि मैं गलत हूँ” वाली tone में प्रतिक्रिया उकसाई जाती है। कई बार पढ़े बिना मैं इसे अपने दिमाग़ में और नहीं रखूँगा
    • Poul-Henning लंबे समय से इस क्षेत्र में सक्रिय और सम्मानित रहे हैं, और वे अमेरिकी सांस्कृतिक दायरे से भी नहीं आते। यह मानने लायक बात है कि उनके पास उपयोगी अंतर्दृष्टि हो सकती है, जो उनकी अपनी संस्कृति से छूट जाने वाली बातों की ओर इशारा करती हो

  • मुझे नहीं लगता कि आयु-सीमा का लंबे समय में FOSS पर बहुत बड़ा असर पड़ेगा। आधुनिक तकनीक, खासकर social media, बच्चों को नुकसान पहुंचाती है, इसलिए regulation अपने आप में समझने लायक है
    अगर regulation तर्कसंगत हो, तो कुछ जिम्मेदारी parents पर रहे, लेकिन smartphone और laptop जैसे consumer devices पर default age restriction लागू की जा सकती है, और age verification से पहले operating system या firmware बदलने से रोका जा सकता है। निशाना सभी software नहीं, बल्कि सिर्फ वे products जो consumer devices पर preinstall होकर आते हैं या commercial रूप से वितरित होते हैं होने चाहिए, और verification के बाद उन्हें आज की तरह खुला होना चाहिए

    • मेरे घर में बच्चे नहीं हैं और कोई दूसरा मेरा device भी इस्तेमाल नहीं करता, फिर भी default state वाले device से bill भरने या tax file करने के लिए मुझे यह साबित करना पड़े कि मैं adult हूं — यह विचार बेतुका है
    • तीन बच्चों के parent के रूप में, मुझे समझ नहीं आता कि सारी जिम्मेदारी parents पर छोड़ने में दिक्कत क्या है। मेरे बच्चे contact sports खेलते हुए कई बार हड्डी तुड़वा चुके हैं और हमें emergency room तक जाना पड़ा, फिर भी मैं sports का समर्थन करता हूं
      Family Link में मैंने कड़े restrictions लगा रखे हैं, लेकिन बार-बार fracture होने पर भी sports की अनुमति देने और screen time का मानसिक असर को ही अलग से विशेष मामला मानने के बीच का फर्क मुझे संदिग्ध लगता है
    • अगर उद्देश्य सिर्फ बच्चों को social media से बचाना है, तो बस ऐसे बच्चों के phone दिए जा सकते हैं जिनमें access न हो या restriction लगा हो। Desktop social media के आदी होने वाले लोग भी कम होते हैं, इसलिए privacy और protection दोनों साथ मिल सकते हैं
    • operating system और browser में आसानी से enable होने वाले integrated parental controls को अनिवार्य बनाना तर्कसंगत है, और चाहें तो browser स्वेच्छा से websites को “child user” का संकेत भी भेज सकता है
      लेकिन मौजूदा bill toddlers को hacker की तरह treat करता है और सभी websites पर user की de-anonymization थोपता है। यह इतना उल्टा है कि इस पर शक होता है कि यह anonymity पर रोक लगाने और पूरे online access को नियंत्रित करने की पहली सीढ़ी है; UK में तो IP छिपाने वाले बच्चों को आधार बनाकर VPN ban तक की चर्चा हो रही है
    • तर्कसंगत regulation को हानिकारक tech features को ही निशाना बनाना चाहिए, न कि किसी third party के सामने पहचान साबित कराने के बाद उसी feature से खुद को नुकसान पहुंचाते रहने देना चाहिए
      यह वैसा ही बेतुका तरीका है जैसे खराब hygiene वाले restaurant को बंद करने के बजाय किसी private security company से customers की ID check करवाई जाए कि वे food poisoning के लिए सहमति देने की उम्र के हैं या नहीं

  • यह अनुमान कि “LLM-assisted code review कोई विशाल disruptive बदलाव नहीं लाएगा” अब पहले से ही हकीकत से मेल नहीं खाता। पिछले कुछ महीनों से एक साल के भीतर तेजी से हुई प्रगति ने LLM के बारे में दृष्टिकोण को काफी पुराना बना दिया है

    • लेखक यह नहीं कह रहा कि LLM बेकार हैं। असली सवाल यह है कि hype खत्म होने के बाद भी LLM code review tools की economics टिकती है या नहीं
    • लेखक समझाता है कि बार-बार के अनुभव के आधार पर उसने शायद “LLM tools ने खोजे सबसे बुरे software bugs” वाली सूची के आधे से ज्यादा bugs पहले ही देख रखे होंगे। उल्टा, यह साबित करने वाला साफ सबूत भी नहीं है कि LLM code review ने पहले से ही कोई बहुत बड़ा बदलाव ला दिया है
    • तर्क यह है कि पहले के model checker की तरह LLM भी कुछ समय तक bugs ढूंढेंगे, लेकिन जब वे bugs ठीक हो जाएंगे तो चीजें फिर सामान्य तरीके पर लौट जाएंगी। इसका मतलब यह बिल्कुल नहीं है कि वे कोई bug ढूंढ ही नहीं सकते

  • tech industry में काम करते हुए मैं ऐसी महिलाओं से मिला हूं जो privacy और राज्य नियंत्रण, दोनों को लेकर सतर्क हैं, और tech industry के बाहर भी ऐसी महिलाओं की कमी नहीं थी जिन्हें डर था कि इस तरह की व्यवस्था महिलाओं पर हमले और भेदभाव के लिए इस्तेमाल होगी। यह सामान्यीकरण करना कि privacy की चिंता करने वाली महिलाएं लगभग होती ही नहीं, अहंकारी या sexist लगता है
    खुद लेखक तो एक पिता के रूप में बेटी की चिंता करने वाले paternalistic नजरिए से इस मुद्दे को गढ़ता है

    • tech industry की कुछ महिलाएं वास्तव में privacy और rule of law को महत्व देती हैं, और साथ ही child safety तथा बेहतर age verification का समर्थन भी करती हैं। साफ वजहों से non-consensual intimate image distribution (NCII) जैसे मुद्दों पर महिलाएं ज्यादा मुखर दिखती हैं

  • व्यवहार में अलग-अलग tasks तेज हो सकते हैं, लेकिन पूरी development process अपने आप बेहतर नहीं हो जाती, और अंततः यह काफी हद तक उस व्यक्ति की क्षमता पर निर्भर करता है जो वास्तव में काम कर रहा है

  • अगर regulators दखल देते हैं, तो Discord के संकेत की तरह closed ecosystems हावी हो सकते हैं। बड़े सार्वजनिक social networks का युग खत्म होकर चीजें शायद ऐसे private networks में बंट जाएं जिनमें लोग एक-दूसरे से जुड़े न हों
    इतिहास को देखें तो कुछ behavior patterns का अनुमान लगाया जा सकता है, लेकिन पूरी dynamics कैसे आगे बढ़ेगी, यह कहना मुश्किल है

    • यह बिना ठोस आधार का अनुमान है, लेकिन बड़े सार्वजनिक social networks को खत्म करना ही age verification bills का अंतिम उद्देश्य लगता है। अगर ऐसा है, तो फिर age verification के जरिए घुमा-फिराकर करने के बजाय उनके business model को कानूनी रूप से सीधे निशाना क्यों नहीं बनाया जाता, यह समझना मुश्किल है

  • उम्र पर निर्भर करेगा, लेकिन संभव है कि बेटियों ने phone मिलने से पहले ही बहुत कुछ खोज लिया हो या दूसरों से सुन लिया हो

    • यहां “वह बातचीत” का मतलब sex education नहीं, बल्कि यह चेतावनी लगता है कि सिर्फ लड़की होने की वजह से अनजान पुरुष उन्हें बिना मांगे penis photos भेज सकते हैं
    • ऐसी दुनिया कैसी दिखेगी जहां मां को अपनी बेटी से “वह बातचीत” अब कभी न करनी पड़े, इसकी कल्पना करना मुश्किल है
    • ऐसी दुनिया नहीं आने वाली जहां बच्चे को अजनबियों, मानव स्वभाव, और उनके इस्तेमाल की जाने वाली तकनीक के खतरों के बारे में समझाना न पड़े। यह कहना कि smartphone हमें ऐसी बातचीत के लिए मजबूर करता है, कुछ वैसा है जैसे कहना कि capitalism हमें भोजन जुटाने के लिए मजबूर करता है; इंसानी बदसूरती smartphone से कहीं पुरानी है
      लेखक का यह रवैया कि अपनी teenage बेटी को बिना किसी जोखिम पर विचार किए हमेशा connected computer, microphone और camera थमा देने के लिए सारे internet users को सरकार के सामने ID दिखानी चाहिए, आलस्य, entitlement, और दूसरों की आजादी के प्रति तिरस्कार दिखाता है

  • “ऐसे model weights जो तभी मुनाफा देते हैं जब वे लाखों बार बिकें, वे जेब में आने वाली storage device में आसानी से समा जाते हैं” — इस वाक्य में कौन-सा model और कौन-सी device की बात हो रही है, यह समझ नहीं आता। Gemma 4 को cyber security issue detection के लिए कोई इस्तेमाल नहीं करता, और लेख की कई पंक्तियों में व्यंग्य और गंभीर बात के बीच फर्क करना मुश्किल है, इसलिए शायद मैंने इसे जरूरत से ज्यादा गंभीरता से पढ़ लिया

    • मतलब model चलाने से नहीं, बल्कि weights को store करने की capacity से है। Kimi 3 जैसे बड़े models भी लगभग 1~2TB के होते हैं, इसलिए वे जेब में आने वाली hard disk में रखे जा सकते हैं
 
GN⁺ 1 일 전
Lobste.rs पर राय

  • इंटरनेट anonymity में कमी असल लोगों की जान ले सकती है, जिनमें उन परिवारों के बच्चे भी शामिल हैं जो LGBTQ+ पहचान को दबाना चाहते हैं

    • LGBTQ+ बच्चे तो बस हिमशैल की नोक हैं, और पूरी transparency हर तरह के लोगों को मौत की ओर धकेल सकती है
      मानवता ऐसे माहौल में विकसित हुई है जहाँ anonymity स्वाभाविक थी, और हम उन survival mechanisms पर निर्भर रहे हैं जो निगरानी न होने पर ही काम करते हैं, साथ ही सामाजिक दिखावे के पीछे अपने तरीके से जीने की गुंजाइश पर भी
      जब तक हम transparent माहौल में survive करना या उससे बचना नहीं सीखते और अत्यधिक transparency पर रोक नहीं लगाते, तब तक अप्रत्याशित बलिदान जारी रहने की संभावना बड़ी है
    • यह बात असहज करती है कि लेखक ने महिलाओं की safety की बात करते हुए अपनी बेटी को बोलने का मौका नहीं दिया और केवल अपने विचारों को आधार बनाया
      वे यह तथ्य भी नज़रअंदाज़ करते हैं कि बच्चों के यौन शोषण का बड़ा हिस्सा परिवार के सदस्य ही करते हैं

  • इस दावे के विपरीत कि पूर्ण privacy protection का समर्थन करने वाली महिला technologists दुर्लभ हैं, हम यहीं मौजूद हैं
    अगर आप यह नहीं समझते कि इंटरनेट पर अपनी पहचान न बताने का अधिकार महिलाओं के survival में कैसे मदद करता है, तो आप खुद उन tech bros के ज़्यादा करीब हो सकते हैं जिनकी आप आलोचना करते हैं

    • यह लेख tech bro शब्द को नापसंद करने की एक और वजह जोड़ देता है

  • भविष्य तयशुदा नहीं है; बच्चों सहित सभी के लिए अधिक सुरक्षित भविष्य बनाते हुए freedom को मानव अधिकार के रूप में guarantee करना और समाज को सामूहिक रूप से मानव अधिकारों की रक्षा करनी चाहिए
    safety और freedom के बीच तनाव हटाई जाने वाली खामी नहीं, बल्कि ऐसी विशेषता है जिसे बनाए रखना ज़रूरी है

  • यह निष्कर्ष समझना मुश्किल है कि FOSS bell-bottoms या hippie culture की तरह सिर्फ एक पीढ़ी तक सीमित घटना है, इसलिए maintainer burnout से आगे बढ़कर projects गायब हो जाएंगे

    • इसे इस तरह पढ़ा जा सकता है कि जब मौजूदा maintainers उपयुक्त उत्तराधिकारी न मिलने पर काम छोड़ेंगे, तो project आगे बढ़ाने वाला कोई नहीं बचेगा—यानी maintainer discontinuity
    • लगता है कि पहले की तुलना में सामाजिक भलाई से अधिक व्यक्तिगत सफलता को प्राथमिकता देने की प्रवृत्ति मज़बूत हुई है
      बड़े पैसे की उम्मीद में blockchain-based prediction market app तुरंत बना लेना, अपेक्षाकृत कम reward और appreciation वाले FOSS maintenance से ज़्यादा आकर्षक लग सकता है
      हालांकि late capitalism की प्रतिक्रिया के रूप में अधिक considerate worldview फिर से ताकत पा सकता है, और मैं भी वह बदलाव लाने के लिए मेहनत करने का इरादा रखता हूँ

  • अगर पीढ़ियों के बीच मूल्यों और practices में बड़ा अंतर है, तो अगली पीढ़ी के लिए मौजूदा maintainers की भूमिका ज्यों-की-त्यों संभालने के बजाय project को पूरी तरह replace करना आसान होगा

  • लगभग 20 साल से देखने के बाद मुझे गहराई से लगता है कि FOSS अपने सबसे बड़े बदलाव से गुजर रहा है
    LLM, maintainers का छोड़ना, Bun·Deno·uv जैसे open source projects में venture investment, non-corporate projects के लिए funding की कमी, और attribution की जरूरत वाले licensed code पर training के बावजूद इसका खुलासा न करने वाला AI-generated code—ये सब एक साथ असर डाल रहे हैं
    उम्मीद है कि EU CADA और उससे जुड़ी open source strategy open source community की लंबे समय से चली आ रही असंतुलन को कम करेगी
    विदेशी कंपनियों को users की identity information माँगने और process करने की अनुमति देना या उन्हें ऐसा करने के लिए मजबूर करना digital sovereignty को सीधे नुकसान पहुँचाता है
    अगर social media ने वह content इकट्ठा किया जिसे लोग publicly share करना चाहते थे, तो LLM-based conversational interfaces उन चिंताओं और photos तक को इकट्ठा करते हैं जिन्हें लोग ज़ुबान पर भी नहीं लाते, इसलिए वे कहीं अधिक डरावने हैं
    पिछले कुछ वर्षों से मैंने अपने day job में digital sovereignty से जुड़ा काम lead किया है, और CADA जिस दिशा में जा रहा है उससे मुझे काफी उम्मीदें हैं