2 पॉइंट द्वारा GN⁺ 2023-09-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक नए Pontiac मालिक ने General Motors Pontiac Division से शिकायत की कि हर शाम ice cream खरीदने के बाद, जब वह vanilla चुनता है, तभी उसकी कार स्टार्ट नहीं होती
  • Pontiac के अध्यक्ष को यह पत्र संदिग्ध लगा, लेकिन उन्होंने एक engineer भेजा, और मौके पर vanilla खरीदने के बाद स्टार्ट फेल होना वास्तव में दोहराकर देखा गया
  • जिन दिनों chocolate और strawberry खरीदी गई, उन दिनों कार स्टार्ट हो गई, लेकिन vanilla खरीदे जाने वाले दिन फिर फेल हुई; यह अजीब लगने वाली शर्त बार-बार सही साबित हुई
  • engineer ने समय, fuel का प्रकार, आने-जाने का समय, और खरीदारी में लगा समय दर्ज किया, और पाया कि केवल vanilla को दुकान के सामने रखे अलग refrigerator से जल्दी खरीदा जा सकता है — यही आवागमन के रास्ते का अंतर था
  • कारण ice cream का flavor नहीं था, बल्कि कम खरीद समय की वजह से इंजन का पर्याप्त ठंडा न हो पाना और उससे पैदा हुआ vapor lock था; यानी अजीब रिपोर्टों को भी observation और reproduction के जरिए जांचना चाहिए

Pontiac की अजीब स्टार्ट समस्या

  • एक Pontiac मालिक ने General Motors की Pontiac Division को दूसरा पत्र भेजा
  • परिवार हर रात खाने के बाद dessert में कौन-सा ice cream flavor खाया जाए, इस पर वोट करता था, और वह हर बार कार चलाकर दुकान से ice cream खरीद लाता था
  • नई Pontiac खरीदने के बाद, समस्या केवल एक खास स्थिति में बार-बार हुई
    • vanilla ice cream खरीदने पर वह दुकान से लौटकर कार स्टार्ट नहीं कर पाता था
    • दूसरे flavor खरीदने पर कार सामान्य रूप से स्टार्ट हो जाती थी
  • उसने माना कि सवाल मूर्खतापूर्ण लग सकता है, फिर भी उसने पूछा कि Pontiac केवल vanilla खरीदने पर ही स्टार्ट क्यों नहीं होती

मौके पर जांच और बार-बार पुनरुत्पादन

  • Pontiac के अध्यक्ष ने पत्र को संदेह से देखा, लेकिन सत्यापन के लिए engineer को भेजा
  • engineer रात के खाने के तुरंत बाद कार मालिक से मिला और उसके साथ ice cream की दुकान गया
  • उस दिन vanilla खरीदने की बारी थी, और जब दोनों कार के पास लौटे, तो सचमुच कार स्टार्ट नहीं हुई
  • इसके बाद तीन दिनों तक शर्तें बदलकर जांच की गई, और नतीजा स्पष्ट था
    • पहले दिन chocolate खरीदने पर कार स्टार्ट हुई
    • दूसरे दिन strawberry खरीदने पर भी कार स्टार्ट हुई
    • तीसरे दिन vanilla खरीदने पर फिर स्टार्ट फेल हुई

अवलोकन रिकॉर्ड से मिला सुराग

  • engineer ने यह मानने से इंकार किया कि कार को vanilla ice cream से एलर्जी है
  • समस्या सुलझने तक वह आता रहा और कई तरह का data दर्ज करता रहा
    • समय
    • इस्तेमाल किया गया fuel
    • दुकान तक आने-जाने का समय
    • खरीदारी में लगा समय
  • निर्णायक सुराग यह था कि vanilla खरीदने में लगने वाला समय दूसरे flavors से कम था
  • दुकान की layout ही इस समय-अंतर की वजह थी
    • vanilla सबसे लोकप्रिय flavor था, इसलिए उसे जल्दी उठाकर ले जाने के लिए दुकान के सामने अलग refrigerator में रखा जाता था
    • दूसरे flavors दुकान के पीछे दूसरे counter पर थे, इसलिए उन्हें ढूंढने और भुगतान करने में कहीं अधिक समय लगता था

असली कारण: vapor lock

  • समस्या का मूल ice cream flavor नहीं, बल्कि कम इंतजार का समय था
  • engineer ने यह समझने के बाद कि असली कारण समय है, vapor lock को मूल कारण के रूप में पहचाना
  • vapor lock रोज हो रहा था, लेकिन दूसरे flavors खरीदने में अधिक समय लगने के कारण इंजन पर्याप्त ठंडा हो जाता था और कार स्टार्ट हो जाती थी
  • vanilla खरीदने पर खरीदारी बहुत जल्दी हो जाती थी, इंजन अभी भी गर्म रहता था, और vapor lock खत्म नहीं होता था, इसलिए कार स्टार्ट नहीं होती थी

सबक

  • ऊपर से बेकार या असंभव लगने वाली समस्या भी वास्तव में सच हो सकती है
  • लक्षण भले ही हास्यास्पद लगें, लेकिन अगर शर्तों को बार-बार जांचा जाए और data इकट्ठा किया जाए, तो असल कारण तक पहुंचा जा सकता है

1 टिप्पणियां

 
GN⁺ 2023-09-21
Hacker News रायें
  • 90 के दशक के आखिर में मेरे कार्यस्थल पर भी कुछ ऐसा ही हुआ था। एक कर्मचारी का माउस दिन के कुछ खास समय पर ही रुक जाता था; सुबह ठीक रहता, दोपहर के आसपास काम नहीं करता, और बाद में फिर चलने लगता था।
    अहम सुराग यह था कि बादल वाले दिनों में वह पूरे दिन ठीक रहता, लेकिन धूप वाले दिनों में वही अजीब व्यवहार दोहराता था। पता चला कि सस्ते ball mouse का प्लास्टिक केस इतना पतला था कि धूप वाले दिन सूरज की रोशनी X/Y axis sensors पर LED से ज्यादा हावी हो जाती थी, और सूरज के खिसकने से छाया बनने के बाद ही वह फिर सामान्य चलता था। शुरुआत में यह बेतुका लगा, लेकिन वजह पूरी तरह तार्किक थी।

    • बहुत पहले iPhone 4 में भी ऐसी ही समस्या थी। अंधेरे में boot करने पर वह Apple logo पर अनंत boot loop में फंस जाता था।
      iOS 7.1.x के लिए Pangu jailbreak के कुछ versions में लगता है कि ambient light sensor value एक खास threshold से कम होने पर boot के दौरान crash हो जाता था। असली वजह अभी भी नहीं पता, लेकिन लगता है Pangu में light sensor को छेड़ने वाला अनावश्यक code शामिल हो गया था [1]
      [1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
      [2] https://www.reddit.com/294wob/
    • उलटी दिशा में भी एक मिलती-जुलती समस्या थी। घर का cable internet speed आम तौर पर ठीक रहता था, लेकिन कभी-कभी बंद तो नहीं होता था, पर ग्लेशियर जैसी धीमी हो जाती थी।
      हर तरह की दिक्कत जांचने के बाद पता चला कि समस्या बारिश में नहीं, बल्कि घने कोहरे या हल्की फुहार के समय होती थी। cable company के technician ने जांचकर बताया कि घर के अंदर सब ठीक था, लेकिन main line से घर तक आने वाली cable में बेहद छोटा सा कट था, जिससे आसपास की नमी अंदर घुसकर connection खराब कर रही थी।
    • घर के countertop ice maker में भी मिलते-जुलते कारण से धूप वाले दिनों में बर्फ अटक जाती है और बहुत ज्यादा बन जाती है।
      ice bin भरने पर infrared beam रुकनी चाहिए और ice making बंद हो जानी चाहिए, लेकिन धूप वाले दिन kitchen की तेज रोशनी sensor को धोखा देकर उसे लगातार बर्फ बनाने पर मजबूर कर देती है। इसलिए ऊपर कोई भी magazine रख दी है ताकि वह ठीक से काम करे।
    • मुझे वह दिन याद आता है जब पता चला कि ऑफिस का CI system vibration के प्रति कमजोर है।
      एक दिन अचानक graphical X client app से जुड़े tests बीच-बीच में fail होने लगे, लेकिन दूसरी conditions में reproduce नहीं हो रहे थे। पता चला कि CI jobs ऑफिस में कहीं रखी desktop machines पर चल रही थीं, और किसी ने एक machine में mouse लगाकर उसे shelf पर छोड़ दिया था। machine का load बढ़ने पर fan तेज हो जाता, vibration बढ़ती और mouse बहुत थोड़ा-सा हिलता; किसी अज्ञात वजह से उसका tests पर side effect पड़ता था। जो machine वहां मौजूद भी नहीं थी, उसे SSH से diagnose कर लेना काफी संतोषजनक लगा।
    • धूप वाले दिनों में मेरी पत्नी की car garage door नहीं खोल पाती, और मेरी car को भी उसे खोलने के लिए बहुत पास जाना पड़ता है। सूरज ढलने के बाद दोनों सड़क से ही तुरंत खोल सकती हैं।
      पता चला कि solar panels या optimizer, inverter ऐसी radio frequency निकाल रहे थे जो garage door remote से interfere करती थी। धूप होने पर जब वे power produce कर रहे होते, interference homelink garage door opener से ज्यादा मजबूत हो जाती थी। कुछ साल पहले garage door opener अचानक ठीक से काम करने लगा, और कुछ दिन बाद पता चला कि inverter खराब हो गया था। FCC rules के हिसाब से शायद installer को इसे ठीक करना चाहिए, लेकिन installation के समय रिश्ते खराब हो गए थे, इसलिए warranty repair से निपटने के बजाय remote छोड़ देना बेहतर लगा।
  • सर्वर रूम वाले दौर की सुनी-सुनाई एक मज़ेदार घटना है। एक दोस्त की कंपनी का सर्वर रोज़ शाम करीब 5 बजे reboot हो जाता था, और operating system की तरफ़ से जो कुछ भी check किया जा सकता था, सब करने पर भी कारण नहीं मिला
    आखिरकार उन्होंने तय किया कि उस समय सर्वर के सामने खड़े रहेंगे, और देखा कि सफ़ाई कर्मचारी कमरे में आया, server rack की power निकालकर vacuum cleaner लगाया, सफ़ाई की, और फिर server rack दोबारा plug कर दिया

    • मेरे साथ भी कमरे के अंदर बैठकर debug करने जैसा एक मामला हुआ था। हम सड़क traffic volume गिनने वाला smart camera product बना रहे थे, जिसे city council जैसी जगहें सड़क पर लगाकर truck, car, motorcycle के आँकड़े निकालती थीं
      कुछ camera रोज़ लगभग उसी समय restart हो जाता था; बिल्कुल वही second नहीं, बल्कि एक दिन 19:12:10, अगले दिन 2 second बाद, फिर उसके अगले दिन भी 2 second बाद—ऐसा साफ़ pattern था। पता चला कि सूर्यास्त के समय सड़क का कोई fixture camera के सामने shadow डालता था, और software उसे गाड़ी समझकर classification data इकट्ठा करने लगता था। shadow असली वाहन से बहुत धीमे चलती है, इसलिए frame से बाहर जाने से पहले memory खत्म हो जाती थी, system hang हो जाता था और watchdog उसे restart कर देता था। समय का pattern इसलिए था क्योंकि सूर्य का angle रोज़ बदलता था, जिससे shadow algorithm को हर दिन थोड़ा देर से धोखा देती थी
    • यह कहानी अब लगभग urban legend जैसी लगती है। Reddit thread[0] में भी लिखा है कि यह 80s में घूमती computer story थी और 1990 में collect की गई थी[1]
      [0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
      [1] https://www.goodreads.com/book/show/3227607-the-devouring-fu...
    • निजी तौर पर भी मुझे ऐसा ही अनुभव हुआ। मैं एक accounting firm का server manage करता था, और print server कभी-कभी सिर्फ़ सुबह 9–10 बजे के बीच reboot होता था
      मैं उस समय slot में एक हफ़्ते तक बैठा रहा और देखा कि lights dim हुईं और reboot हुआ। बगल वाले office का lawyer आया और उसने PC, printer और coffee pot को एक ही power strip से एक साथ चालू किया; starting current की वजह से उस circuit का voltage गिर गया जिससे server जुड़ा था। UPS था, लेकिन उस समय के consumer-grade UPS सिर्फ़ power outage संभालते थे; मैंने voltage 85V तक गिरता मापा, और असल में 95V से कम पर server reboot हो जाता था
    • 1999 में Germany के Stuttgart के दक्षिण-पूर्व में एक छोटे municipality town hall में, आधे साल में तीसरी बार MS SQL DB के corrupt index ठीक करने site पर गया था
      शुक्रवार की शुरुआती दोपहर थी, गर्म और उमस भरा मौसम था और thunderstorm आने ही वाला था। करीब 16:00 बजे responsible person आया और बोला कि 17:00 बजे पूरी building की बिजली काट देंगे, इसलिए जल्दी करो। वे हर शुक्रवार energy बचाने के लिए power off कर रहे थे, और इत्तफ़ाक़ से हर शुक्रवार 16:30 बजे DB cleanup scheduled था। इसलिए बचे हुए एक घंटे में problem ठीक की, उस हफ़्ते का schedule cancel किया और DB server को manually shutdown किया। हर हफ़्ते forcefully power काटकर वे Netware server और collection software DB server में production outage बना रहे थे, और maintenance contract के तहत हर बार हमें ही ठीक करना पड़ता था। आखिर लगभग एक महीने बाद ही forced power shutdown को Saturday morning तक टाला गया, ताकि backup job पूरा होने के बाद server ठीक से shutdown हो सके
  • 80s में मेरे brother-in-law की चलायी GM minivan याद आती है। यह car मेरे father-in-law ने दी थी, जो GM automotive engineer थे। कभी-कभी random तरीके से start नहीं होती थी और पूरा electrical system dead जैसा लगता था
    brother-in-law को car के बारे में ज्यादा न जानने वाला माना जाता था, इसलिए father-in-law ने उसकी शिकायतों को गंभीरता से नहीं लिया। आखिर एक महीने के लिए car बदलकर चलाने का फैसला हुआ, और GM Technical Center parking lot में problem reproduce हो गई। आसपास जुटे GM engineers भी यह नहीं समझ पाए कि electrical system dead जैसा क्यों दिख रहा है, इसलिए brother-in-law की बात सही साबित हुई

    • 2009 Mercedes SLK में भी यही symptom था। 99.9% समय सब perfect था, लेकिन करीब हज़ार में एक बार वह start करने की कोशिश तक नहीं करती थी—न click sound, न key घुमाने की recognition, बिल्कुल dead जैसी
      कुछ घंटे बाद वह ऐसे start हो जाती जैसे कुछ हुआ ही न हो, इसलिए service center भी diagnose नहीं कर पाता था। बाद में off-road camping के दौरान भी start न होने लगा और जीवन पर असर पड़ने लगा। आखिर घर के driveway में start न होने की हालत में उसे एक independent garage तक tow कराया, जहाँ problem फिर reproduce हो गई। mechanic ने ECU module replacement या fuse box खुद बदलने का सुझाव दिया; ECU कई हज़ार dollars का था, लेकिन fuse box replacement labour सहित 200 dollars से कम था, इसलिए दूसरा option चुना। 6–7 साल बाद भी वही car मुख्य और इकलौती car है, और उसके बाद एक भी mechanical problem नहीं आई
    • Heisenbug पूरे system design failure का संकेत है। यह उन projects में दिखता है जिन्हें troubleshooting आसान बनाने के लिए design नहीं किया गया, जहाँ subsystems tightly coupled होते हैं, और सब कुछ तार और chewing gum से बस किसी तरह जुड़ा होता है
      GM cars के बदनाम दौर में लोगों को पागल कर देने वाली mysterious electrical problems होना पूरी तरह plausible है
    • GM cars की बदनामी है कि वे कभी-कभी ऐसी अजीब problems पैदा करती हैं जैसे उनमें भूत घुस गया हो। 1990 के बाद GM cars overall reliability में Japanese cars के काफ़ी करीब आ गईं, फिर भी ऐसा है
    • इस thread में ऐसी बहुत cars हैं जो intermittent रूप से on नहीं होतीं, लेकिन पहले ऐसी cars भी थीं जो intermittent रूप से off नहीं होती थीं। कम से कम headlights बंद नहीं होती थीं
      लगता है कहीं कोई relay overheat होकर closed state में रह जाता था, लेकिन न मैं खुद debug कर पाया और न मेरा cousin, जो auto mechanic था, उसे ढूँढ पाया। हमने बहुत ज़ोर नहीं लगाया; जब ऐसा होता, fuse निकाल देते और अगली सुबह फिर लगा देते
    • अंदाज़ा लगाऊँ तो शायद नई battery की जरूरत रही होगी। मेरी GM car भी battery पुरानी होने पर start के समय अजीब behavior दिखाती थी
      starter अक्सर ठीक घूमता था, लेकिन electronics किसी अजीब state में फँस जाते थे और battery disconnect करके hard reset करने पर ही ठीक होते थे
  • पुराने घर में इलेक्ट्रॉनिक डिवाइसों से जुड़ी एक अजीब दोहराई जाने वाली घटना हुई थी। हफ्ते के किसी खास दिन आधी रात को, जगह पर लगे इलेक्ट्रॉनिक उपकरणों से द्वितीय विश्व युद्ध के किसी राजनीतिक भाषण की रिकॉर्डिंग जैसी आवाज़ बहुत हल्की सुनाई देती थी
    आवाज़ इतनी धीमी थी कि किसी एक जगह को pinpoint करना मुश्किल था, और शब्द समझ नहीं आते थे, इसलिए लगता था जैसे कोई पुरानी रिकॉर्डिंग हर तरफ़ से एक साथ सुनाई दे रही हो। प्लग निकाल देने पर भी, घर में बिजली कट जाने पर भी यह जारी रहता था। लगा कि मैं पागल हो रहा हूं या घर में हिटलर का भूत है, लेकिन बाद में कार रेडियो पर वैसी ही चीज़ सुनकर समझ आया। एक Catholic AM radio station उसी दिन उसी समय Gregorian chant और sermon के साथ प्रसारण शुरू करता था, और घर की वायरिंग किसी तरह AM radio receiver की तरह काम कर रही थी, जिससे कुछ components वायरलेस signal पर आए audio को vibration के रूप में निकाल रहे थे

    • AM radio कई मायनों में भयानक transmission format है, लेकिन इसका एक फायदा यह भी है कि इसे इस तरह आवाज़ के रूप में demodulate करना बहुत आसान है
    • मेरे workplace के पास एक factory के सामने करीब 25 feet का एक हिस्सा है जहां लगभग सभी FM stations Muzak से दब जाते हैं। उस factory में क्या चल रहा है, पता नहीं, और मैंने सच में FCC से संपर्क करने के बारे में सोचा था
    • सचमुच हैरान कर देने वाली बात है। मैं होता तो खिड़कियों के आसपास नमक की boundary बना रहा होता
  • जब भी बेटा American Truck Simulator खेलता था, laptop की screen बंद हो जाती थी, और screen काली रहने के दौरान truck सड़क से बाहर चला जाता था
    मैं उसी laptop पर खेलता तो ऐसा नहीं होता था, इसलिए बेटे को पूरा यकीन था कि उस पर कोई श्राप है। कई दिनों तक ऐसा दोहराने के बाद, मैंने बगल में बैठकर उसे खेलते देखा और नोटिस किया कि उसकी watch strap magnetic clasp वाली metal band थी। उसकी कलाई की position laptop के Hall sensor को trigger कर रही थी, जिससे laptop को लगता था कि lid बंद हो गई है। बेटे, मैं और मेरी पत्नी—हम सबने राहत की सांस ली कि उस पर कोई श्राप नहीं था

    • इसी bug की वजह से Apple ने screen angle sensor को दूसरे तरीके से बदल दिया। और Apple की तरह, उन्हें उस sensor को serialize करने का बहाना भी मिल गया
      https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i...
    • university helpdesk में भी कभी-कभी यह देखने को मिलता था। खुले हुए MacBook को बंद MacBook के ऊपर रख देने से भी ऐसा हो सकता था, और magnets आसानी से align होकर screen बंद कर देते थे
  • ऐसी कहानियों ने ही Car Talk को इतना मजेदार बनाया था। यह सिर्फ mechanics द्वारा car ठीक करने की बात नहीं थी, बल्कि स्थितियां इतनी अजीब और अनोखी होती थीं कि दिलचस्प लगती थीं
    लंबे समय से काम कर रहे mechanics को ऐसी अजीब परिस्थितियां इतनी ज्यादा देख लेने के कारण उन्हें लगभग सामान्य मानते सुनना भी बहुत मजेदार था, और ऊपर से वे बेहतरीन storyteller भी थे

    • “workshop में जाओ और सबसे उम्रदराज़ व्यक्ति को खोजो। शायद वह carburetor संभाल सकता हो”
  • मेरे लिए सबक “बेतुकी लगने वाली समस्या भी कभी-कभी सच होती है” से ज्यादा यह है कि user की समस्या आमतौर पर सच में मौजूद होती है, लेकिन कारण diagnose करने की उसकी क्षमता पर भरोसा मत करो

    • दूसरे शब्दों में, कहानी में देखे गए facts और inference को अलग करना चाहिए। inference को छोड़ देने का मतलब यह नहीं कि observation को भी अनदेखा कर दिया जाए। यह XY problem जैसा भी है
    • proximate cause और root cause में बड़ा फर्क होता है। proximate cause vanilla ice cream खरीदना है, और root cause vapor lock है
      पत्र में यह दावा नहीं था कि ice cream root cause है; उसने बहुत साफ किया था कि वह proximate cause है। Pontiac के president और वह “lesson” लिखने वाले व्यक्ति ने दोनों को मिला दिया होगा, लेकिन जांच करने वाले engineer ने ऐसा नहीं किया
    • problem solver को किसी एक theory में बहुत जल्दी फंसना नहीं चाहिए। इससे बाकी mismatch करती जानकारी आसानी से छूट सकती है
    • title जानबूझकर provocative था, लेकिन पढ़ते ही सबसे पहले timing issue दिमाग में आया। शायद timing issues से अक्सर dealing करने की वजह से किस्मत से यह ख्याल आया हो, लेकिन मैंने यह सोचकर वह hypothesis छोड़ दी कि user ने इतना तो notice किया ही होगा। ऐसा नहीं था
      development work के दौरान helpdesk भी कर चुका हूं, और experience यह है कि users किसी random fact को आसानी से problem का cause ठहरा देते हैं। “correlation is causation” या post hoc ergo propter hoc जैसे heuristics मदद कर सकते हैं, लेकिन अगर वे inference की जगह ले लें तो खराब है। users अपनी इस्तेमाल की चीज़ों के काम करने का तरीका नहीं जानते, इसलिए ठीक से diagnose करना मुश्किल होता है, और जो users सोचते हैं कि “मुझे ऐसी चीज़ों की थोड़ी समझ है” वे अक्सर सबसे मुश्किल होते हैं
  • मेरी पत्नी की car में अभी washer fluid कम है, लेकिन driving के दौरान warning सिर्फ एक खास जगह पर आती है। घर से कोई खास distance नहीं, बल्कि बिल्कुल वही location है
    शुरू में लगा कि शायद कहीं जाकर लौटने में लगे समय की वजह हो, लेकिन उससे पहले 5 minutes drive की हो, 5 miles, 1 hour या 60 miles—हमेशा उसी location पर screen और sound warning आती है। एक और clue बस इतना है कि वह जगह ज्यादातर phones/carriers के लिए dead zone है। washer fluid भर देने से mystery फिलहाल dormant हो गई है, लेकिन मुझे curiosity है कि क्या सारी warnings वहीं आती हैं। लगता है जैसे उस spot पर vehicle telemetry छेड़ी जाती है, जागती है और कुछ बोलती है

    • उस location की ढलान sensor point पर liquid level को low बना सकती है। किसी भी axis पर कोई unusual slope है क्या?
    • मेरे मामले में भी ऐसा ही था, लेकिन साफ था कि उस location का हल्का curve और relatively high speed मिलकर washer fluid को tank के एक तरफ धकेल देते थे। लगता है sensor दूसरी तरफ लगा है
    • मेरी Subaru highway exit पर ही washer fluid warning दिखाती है, speed और slope change की वजह से
    • यह किसी strong electromagnetic interference वाली जगह जैसी लगती है। underground sensor वाली traffic light, high-voltage lines के नीचे, substation के पास, या high-power radio antenna के पास हो सकता है
      sensor को “पर्याप्त liquid” से “कम” की तरफ थोड़ा धकेलने जितनी अजीब interference दे सकता है
    • आजकल मेरी 2019 VW Passat में भी यही हो रहा है। accelerate करने, brake लगाने या लंबे समय तक corner लेने पर warning आती है
      बस container के अंदर liquid के हिलने की समस्या है। आज मैंने windshield थोड़ा साफ किया ताकि car low level indicator को लगातार on रखे
  • Computer Science लैब में Java असाइनमेंट करते हुए एक रात, संबंधित प्रोफेसर गुजरते हुए बोले, “अरे, उस मशीन पर तो तुम्हें किस्मत की जरूरत पड़ेगी”
    वह मशीन कभी भी कोई Java प्रोग्राम चला नहीं पाती थी और शानदार तरीके से क्रैश हो जाती थी, लेकिन C++ या Python ठीक चलते थे. शुरुआत में भरोसा न करने वाले प्रोफेसर का प्रोग्राम भी उस मशीन को क्रैश करा गया. एक तकनीशियन और प्रोफेसर ने करीब 2 हफ्ते तक जांच की, तो पता चला कि JVM हर बार शुरू होते समय integer 12 को उसी RAM address पर allocate करता था, और उस hardware address वाला RAM chip खराब था. जब भी उस address पर allocate करने की कोशिश होती, क्रैश हो जाता, और खराब RAM stick बदलते ही समस्या तुरंत हल हो गई

    • “इस बिंदु पर स्वाभाविक निष्कर्ष दो में से एक है. या तो कोई गंभीर hardware समस्या है, या binary में कोई खतरनाक memory corruption bug है”
      https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
      निष्कर्ष का spoiler नहीं दूंगा. यह लंबी और घुमावदार debugging यात्रा है, पढ़ने लायक. HN discussion:
      https://news.ycombinator.com/item?id=15845118
  • यह कहानी confounding variable का एक मजेदार उदाहरण है
    causal inference में confounding variable वह variable होता है जो dependent variable और independent variable दोनों को प्रभावित करके एक नकली association बनाता है. यह correlation भर से समझाया नहीं जा सकने वाला causality concept है, और “correlation का मतलब causation नहीं होता” के महत्वपूर्ण quantitative कारणों में से एक है
    https://en.wikipedia.org/wiki/Confounding
    statistical model में लिखें तो इसे S = f(H, I, T) जैसा देखा जा सकता है. S यह है कि कार start होती है या नहीं, H engine temperature है, I चुनी गई ice cream का type है, और T ice cream खरीदने में लगा समय है. अगर T कम हो, तो engine ज्यादा गर्म रहता है और vapor lock के प्रति अधिक vulnerable हो जाता है, जिससे S पर असर पड़ता है; और vanilla ice cream की location उसे जल्दी खरीदना संभव बनाती है, इसलिए वह I से भी जुड़ता है. इसलिए I और S के बीच एक नकली relationship बन जाता है

    • दिलचस्प explanation है, लेकिन क्या T का I पर असर होने के बजाय I का T पर असर नहीं होता? क्योंकि ice cream का type ही store के अंदर लगने वाला समय तय करता है