1 คะแนน โดย GN⁺ 2023-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เรื่องอื้อฉาวการดำเนินคดี Post Office Horizon ของสหราชอาณาจักรถูกมองว่าเป็นหนึ่งในกรณีตัดสินผิดครั้งใหญ่ของสหราชอาณาจักรยุคใหม่ และแสดงให้เห็นว่าไม่ใช่แค่ความล้มเหลวของบุคคลและองค์กรเท่านั้น แต่กฎหมายและกระบวนพิจารณาของศาลมีบทบาทอย่างไรด้วย
  • ศาลจะสันนิษฐานว่า อุปกรณ์เครื่องจักรทำงานตามปกติ หากไม่มีพยานหลักฐานโต้แย้ง และจุดตั้งต้นนี้ก็ถูกนำมาใช้กับบันทึกของคอมพิวเตอร์ด้วย
  • ภายใต้ ข้อสันนิษฐานทางพยานหลักฐาน นี้ บันทึกจากคอมพิวเตอร์เพียงอย่างเดียวก็อาจใช้พิสูจน์ข้อเท็จจริงอย่างยอดขาดบัญชีได้ และทำให้เกิดโครงสร้างที่จำเลยต้องเป็นฝ่ายพิสูจน์ความผิดพลาด
  • Section 69 ของ Police and Criminal Evidence Act ปี 1984 วางกฎในทางตรงกันข้าม โดยกำหนดให้อัยการต้องแสดงให้เห็นว่าคอมพิวเตอร์ทำงานตามปกติ แต่ถูกยกเลิกในปี 1999
  • หาก Section 69 ยังคงมีผลอยู่ วิธีที่การดำเนินคดีของ Post Office ดำเนินไปอาจแตกต่างออกไป และหลังการยกเลิก ภาระก็กลับไปตกอยู่กับฝ่ายจำเลยอีกครั้ง

ความรับผิดของเรื่องอื้อฉาว Post Office Horizon และกระบวนการทางกฎหมาย

  • Post Office prosecutions scandal ถูกนับว่าเป็นหนึ่งในกรณีตัดสินผิดหมู่ครั้งใหญ่ที่สุดของสหราชอาณาจักรยุคใหม่
  • คดีนี้ประกอบด้วยความล้มเหลวทั้งในระดับบุคคลและระดับสถาบัน อีกทั้งยังมีเอกสารทางกฎหมายและพยานหลักฐานจำนวนมหาศาลจนยากจะมองภาพรวมทั้งหมด
  • การวิเคราะห์จำนวนมากมุ่งไปที่ความล้มเหลวของผู้บริหาร Post Office ทนายความ และ Fujitsu ผู้ให้บริการซอฟต์แวร์
  • อย่างไรก็ดี กฎหมายและกระบวนการที่ถูกนำมาใช้ก็เป็นส่วนหนึ่งของคดีเช่นกัน และความรับผิดก็ไม่ได้เบาลง เพราะผู้มีอำนาจตัดสินใจรู้อยู่แล้วหรือควรรู้อยู่แล้วว่ามันอาจทำงานอย่างโหดร้ายต่อจำเลยได้

ข้อสันนิษฐานทางพยานหลักฐานว่า “คอมพิวเตอร์ทำงานตามปกติ”

  • ข้อสันนิษฐาน (presumption) ในความหมายของนักกฎหมาย คือกลไกที่ศาลยอมรับสภาพบางอย่างเป็นค่าเริ่มต้นเมื่อไม่มีพยานหลักฐานโต้แย้ง
  • ถ้อยคำแบบดั้งเดิมคือ “หากไม่มีพยานหลักฐานโต้แย้ง ศาลจะสันนิษฐานว่าอุปกรณ์เครื่องจักรอยู่ในสภาพการทำงานตามปกติในเวลาที่เกี่ยวข้อง”
  • ในที่นี้ อุปกรณ์เครื่องจักร รวมถึงคอมพิวเตอร์ด้วย
  • ข้อสันนิษฐานนี้ไม่ได้หมายความว่าศาลจะเชื่อคอมพิวเตอร์เสมอในทุกกรณี แต่เป็นเพียงจุดตั้งต้นที่สามารถหักล้างได้ด้วยพยานหลักฐาน
  • ตราบใดที่ยังไม่พิสูจน์สภาพตรงกันข้าม ศาลก็อาจยอมรับสภาพนั้นเป็นข้อเท็จจริงได้

เหตุผลที่ต้องมีข้อสันนิษฐานและความเสี่ยงของมัน

  • การที่ศาลใช้ข้อสันนิษฐานนั้นไม่ใช่ปัญหาในตัวเอง เพราะหากไม่มีข้อสันนิษฐาน หลายคดีก็ยากจะจัดการได้ในทางปฏิบัติ
  • ข้อสันนิษฐานช่วยจำกัดประเด็นของคดีให้แคบลงจนอยู่ในขอบเขตที่จัดการได้
    • สัญญาอาจถูกมองว่าไม่ใช่เอกสารฉ้อโกง เว้นแต่จะพิสูจน์ได้ว่าเป็นของปลอม
    • จำเลยอาจถูกปฏิบัติว่าไม่มีอาการวิกลจริต เว้นแต่จะพิสูจน์ได้ว่ามี
  • ประเด็นสำคัญคือ สภาพใดถูกกำหนดให้เป็นค่าเริ่มต้น และฝ่ายใดต้องเป็นผู้หักล้างค่าเริ่มต้นนั้น
  • หากเนื้อหาของข้อสันนิษฐานไม่สมจริง หรือเงื่อนไขในการหักล้างยากเกินไป ข้อสันนิษฐานก็จะไม่ใช่เครื่องมือช่วยกระบวนการยุติธรรม แต่กลายเป็น เครื่องมือที่ก่อให้เกิดการตัดสินผิด

โครงสร้างที่ทำให้บันทึกคอมพิวเตอร์กลายเป็นฐานของความผิด

  • กฎที่ถือว่าคอมพิวเตอร์ทำงานตามปกตินั้นเป็น ข้อสันนิษฐานทางพยานหลักฐาน
  • หากไม่มีหลักฐานว่าคอมพิวเตอร์ทำงานผิดปกติ ศาลก็อาจเห็นว่าบันทึกจากคอมพิวเตอร์เพียงอย่างเดียวก็พิสูจน์ข้อเท็จจริงที่เกี่ยวข้องได้
  • ตัวอย่างเช่น หากบันทึกคอมพิวเตอร์แสดงยอดขาดทางการเงินของนายไปรษณีย์หรือพนักงานหญิงประจำไปรษณีย์ ศาลก็อาจรับสิ่งนั้นเป็นหลักฐานของยอดขาดจริงได้
  • หากต้องการสั่นคลอนข้อสมมตินี้ จำเลยต้องแสดงให้เห็นว่าคอมพิวเตอร์ไม่ได้ทำงานตามปกติ
  • เมื่อพยานหลักฐานหลักของการฟ้องคดีคือบันทึกคอมพิวเตอร์ โครงสร้างนี้ก็ลงเอยเป็น “computer says guilty

การนำ Section 69 มาใช้และการยกเลิก

  • ข้อสันนิษฐานทางพยานหลักฐานนี้ไม่ได้ทำงานไปในทิศทางเดิมเสมอมา
  • Police and Criminal Evidence Act 1984 Section 69 ที่ประกาศใช้ในปี 1984 ได้กลับทิศทางของข้อสันนิษฐานนี้
  • ภายใต้ Section 69 ไม่ใช่จำเลยที่ต้องแสดงความผิดพลาดของคอมพิวเตอร์ แต่เป็น อัยการที่ต้องแสดงว่าคอมพิวเตอร์ทำงานตามปกติ
  • บทบัญญัตินี้เข้ามาแทนที่จุดยืนตามกฎหมายจารีตเดิมที่ว่า “หากไม่มีพยานหลักฐานโต้แย้ง ก็ให้สันนิษฐานว่าอุปกรณ์เครื่องจักรอยู่ในสภาพปกติ”
  • หากในช่วงที่ Post Office ดำเนินคดีกับนายไปรษณีย์และพนักงานหญิงประจำไปรษณีย์นั้น Section 69 ยังมีผลอยู่ การดำเนินคดีอาจแตกต่างออกไป
  • Section 69 ถูกยกเลิกในปี 1999 และข้อสันนิษฐานตามกฎหมายจารีตเดิมก็กลับมาใช้อีกครั้ง
  • นับจากนั้น โครงสร้างจึงกลายเป็นว่าไม่ใช่อัยการที่ต้องแสดงก่อนว่าคอมพิวเตอร์ทำงานตามปกติ แต่เป็น จำเลยที่ต้องแสดงว่าคอมพิวเตอร์ไม่ได้ทำงานตามปกติ
  • Section 69 ถูกยกเลิกได้อย่างไร และเหตุผลของการยกเลิกนั้นสมเหตุสมผลหรือไม่ เป็นประเด็นของบทความถัดไป

1 ความคิดเห็น

 
GN⁺ 2023-10-02
ความคิดเห็นจาก Hacker News
  • ความประทับใจที่ได้เมื่อครั้งล่าสุดที่ผมดูเรื่องอื้อฉาวของ Post Office คือ คำพูดที่ว่า “เราเชื่อมั่นใน ระบบ IT มากเกินไป” นั้นดูเหมือนเป็นข้ออ้างที่สะดวกเสียมากกว่า
    ฝ่ายผู้บริหารระดับบนรู้ดีว่ามีปัญหา และรู้ด้วยว่ากำลังฟ้องร้องคนบริสุทธิ์ แต่ดูเหมือนยังเดินหน้าต่อเพื่อปกปิดความล้มเหลวของตัวเอง หากเป็นเช่นนั้นก็ควรต้องมี โทษจำคุกจริง อย่างมีนัยสำคัญ การขัดขวางกระบวนการยุติธรรมไม่ใช่อาชญากรรมเล็กน้อย และยังมีข้อสงสัยว่า Paula Vennells จงใจโกหกต่อรัฐสภาด้วย

    • มีหลักฐานจำนวนไม่น้อยว่า การที่ผู้มีอำนาจในบอร์ดของ Post Office เพิกเฉยต่อหลักฐานจากผู้จัดการไปรษณีย์สาขาย่อย ได้รับอิทธิพลอย่างมากจากข้อเท็จจริงที่ว่าพวกเขาหลายคนเป็น ชาวเอเชีย เช่น เชื้อสายอินเดีย บังกลาเทศ หรือปากีสถาน
      ดังนั้น บอร์ดของ Post Office จึงมีอุปสรรคทางจิตใจจากการเหยียดเชื้อชาติที่ทำให้ไม่สามารถเชื่อมโยงเบาะแสต่าง ๆ เข้าด้วยกันได้ และแม้หลังจากเผชิญหลักฐานท่วมท้นว่ามี คำพิพากษาว่ามีความผิดอันเป็นเท็จ หลายร้อยคดี ก็ยังขาดคุณธรรมจนยิ่งยืนกรานต่อไป เรื่องนี้เป็นทั้งเรื่องน่าเศร้าของความล้มเหลวทางเทคโนโลยี และเป็นการกล่าวโทษวัฒนธรรมบอร์ดบริษัทของอังกฤษด้วย หายนะครั้งนี้เป็นสิ่งที่นิตยสาร Private Eye รายงานมาเกิน 10 ปีแล้ว
    • ผมสงสัยว่าทำไมถึงคิดว่ากฎการลงโทษ ซึ่งสุดท้ายก็คือการเอาคนเข้าคุกหรือเก็บภาษีกับพฤติกรรมที่ได้รับอนุญาต จะสามารถแก้ปัญหานี้ได้
      การเสนอให้ กำจัดอำนาจนั้นในเชิงโครงสร้าง น่าจะถูกต้องกว่าไม่ใช่หรือ
    • ถ้าโทษที่ผู้บริหารคาดว่าจะได้รับรุนแรงกว่านี้ ปัญหาของผู้จัดการไปรษณีย์สาขาย่อยจะถูก แก้ได้เร็วขึ้น หรือช้าลงกันแน่?
  • หลังจากใช้ชีวิตมาทั้งชีวิตกับการแก้บั๊ก บางครั้งแค่ข้อเท็จจริงที่ว่าระบบคอมพิวเตอร์มัน überhaupt ทำงานได้ก็ยังน่าทึ่งแล้ว
    ผมเคยเจอเรื่องส่วนตัวที่คล้ายกับระบบล้มเหลวของ Post Office แม้จะนำหลักฐานมาให้ดู ทุกคนก็ยังปฏิเสธ ความเป็นไปได้ที่ระบบคอมพิวเตอร์จะผิด เพราะการขุดลงไปทำความเข้าใจมันยุ่งยากเกินไป

    • ผมเห็นด้วยกับคำว่า “น่าทึ่งที่ระบบคอมพิวเตอร์ überhaupt ทำงานได้”
      เพราะได้เห็นมาว่าซอฟต์แวร์ถูกสร้างขึ้นอย่างไร ผมจึงไม่เข้าใจเลยว่าทั้งหมดมันทำงานได้อย่างไร คำตอบของผมต่อปฏิทรรศน์นี้คือ จริง ๆ แล้วมันไม่ได้ทำงานทั้งหมดหรอก เราถูกฝึกให้ยอมรับสิ่งที่ไม่ทำงานว่าเป็นอย่างอื่น ผู้คนมองระบบคอมพิวเตอร์เป็นสิ่ง ทรงอำนาจและปราศจากความผิดพลาด หรือไม่ก็ปฏิบัติกับมันเป็น แพะรับบาป
    • ถ้าเติมความละเอียดอีกเล็กน้อย ซอฟต์แวร์ยอดนิยมจำนวนมากพังถึงขั้นที่ฟังก์ชันหลัก หรือก็คือเหตุผลที่ซอฟต์แวร์นั้นมีอยู่ ไม่ทำงานเลย
      ตัวอย่างเช่น เว็บไซต์สายการบินอย่าง TAP, Vueling, KLM ที่ผมใช้ในช่วง 2 ปีที่ผ่านมา มีบั๊กบ่อยครั้งที่ทำให้จองตั๋วหรือเข้าสู่ระบบบัญชีไม่ได้ และผมมองว่ามันไม่ทำงานมากกว่าทำงาน Instagram และ Google ปิดใช้งานบัญชีอัตโนมัติโดยแทบไม่มีเหตุผล ส่วน Instagram ผมเจอ 3 ครั้งในสองเดือนแล้วก็ยอมแพ้ เลิกใช้ไปเลย Skype ถ้าใครใช้ก็คงไม่ต้องอธิบาย ส่วน Teams ล้มเหลวในแบบน่าทึ่ง เช่น ต่อให้ “อัปเดต” แค่ไหน ปุ่มปิดไมค์ก็ไม่ได้ปิดเสียงจริง ๆ, ระหว่างพิมพ์แชตลำดับตัวอักษรในประโยคกลับด้าน, หรือระหว่างโทรอยู่ดี ๆ ก็ปิดตัวลงและไม่ตอบสนอง การสูญเสียผลิตภาพ แบบนี้น่าจะมีมูลค่าสูงมากทั่วโลก และค่าจ้างพนักงานที่บริษัทต่าง ๆ เสียไปอาจมากกว่าค่าไลเซนส์ที่จ่ายให้ Microsoft ด้วยซ้ำ Telegram จัดการจอภาพภายนอกได้ไม่ดี ทำให้สเกลเพี้ยนและต้องรีสตาร์ต ส่วน iCloud แม้อุปกรณ์ทุกเครื่องจะเชื่อมต่อดี ก็ยังใช้เวลาซิงก์ไฟล์ตั้งแต่ไม่กี่วินาทีไปจนถึงราวหนึ่งชั่วโมง
    • คนส่วนใหญ่มักเลือกทางที่ง่ายกว่า คือคิดว่าทุกอย่างสมบูรณ์แบบ แทนที่จะยอมรับว่าทุกอย่างทำงานได้แบบ “พอประมาณ”
      ทั้งที่เห็นหลักฐานตรงข้ามอยู่เรื่อย ๆ แต่ในฐานะวิศวกร ผมมองว่านี่เป็นเรื่องธรรมชาติและมีประสิทธิภาพ เราต้องจัดลำดับความสำคัญ และบั๊กบางตัวก็สำคัญน้อยกว่าบั๊กอื่น ผมคิดว่าควรทุ่มความพยายามให้การศึกษา สาธารณสุข และงานวิจัยพื้นฐาน มากกว่าการแก้บั๊กทุกตัวในซอฟต์แวร์ทุกชิ้น
    • เหตุที่เรื่องแบบนี้เกิดขึ้นบ่อย เพราะโดยทั่วไปเครื่องจักรทำงานได้ดีอยู่ 99% ของเวลา
      ดังนั้นเมื่อมันเริ่มล้มเหลวในอีก 1% ผู้คนจึงมองข้าม เพราะก่อนหน้านั้น 99% มันทำงานได้ พวกเขาถูกฝึกให้เชื่อถือผลลัพธ์ จนความสงสัยไม่ผุดขึ้นมาเลย นึกถึงหนังสือ Systemantics: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
      หนึ่งในแก่นสำคัญของหนังสือนั้นคือ ความเข้าใจผิดเชิงปฏิบัติการ ที่ว่า “ระบบไม่ได้ทำสิ่งที่มันบอกว่าทำจริง ๆ” ไม่ใช่แค่คนทั่วไป วิศวกรเองก็มักลืมเรื่องนี้เช่นกัน การที่ระบบบอกว่ามันทำ X ไม่ได้แปลว่ามันทำ X จริง ๆ เราต้องบ่มเพาะความกังขาที่ดีต่อระบบ IT ที่ซับซ้อน ส่วนใหญ่ของเวลาอาจไม่ล้มเหลว แต่สุดท้ายสักวันมันก็จะล้มเหลว
    • การเติบโตอย่างรวดเร็วของอุตสาหกรรมซอฟต์แวร์เป็นทั้งสาเหตุของความโกลาหลที่เก็บกวาดไม่ไหว และเป็นเหตุผลที่บริษัทต่าง ๆ ใช้เงินอย่างบ้าคลั่งเพื่อทำให้มันพอเดินต่อไปได้
      อย่างน้อยก็รู้สึกแบบนั้น
  • หนึ่งในปัญหาใหญ่ของการฟ้องร้องเหล่านี้คือ ผู้มีอำนาจฟ้องคดี คือ Post Office เอง
    ก่อนคดีนี้ ผมไม่รู้เลยว่า Post Office มีอำนาจแบบนั้น เท่ากับว่า Post Office เป็นทั้งผู้ร้องทุกข์และหน่วยงานฟ้องคดีในเวลาเดียวกัน “Post Office Investigation Branch (IB) เป็นองค์กรสืบสวนอาชญากรรมที่ได้รับการรับรองที่เก่าแก่ที่สุดในโลก ตลอดกว่า 335 ปีที่ผ่านมา องค์กรนี้ตรวจพบอาชญากรรมที่เกี่ยวกับไปรษณีย์และฟ้องร้องผู้กระทำผิดเหล่านั้น”
    https://www.postalmuseum.org/blog/the-post-office-investigat...

    • ในอังกฤษ ใคร ๆ ก็สามารถยื่นฟ้องคดีอาญาได้
      ในทางทฤษฎี นี่เป็นเครื่องมือในการเอาผิดผู้มีอำนาจ แต่ค่าใช้จ่ายสูงมาก ทำให้ การฟ้องคดีอาญาโดยเอกชน แทบทั้งหมดในความเป็นจริงถูกยื่นโดยบริษัท
  • เพิ่งเคยได้ยินเรื่องอื้อฉาวนี้ครั้งแรก
    สงสัยว่าปัญหาหลักของซอฟต์แวร์ที่ทำให้เกิดความคลาดเคลื่อนคืออะไร เป็นอะไรทำนองการเชื่อมต่อหลุดหรือเปล่า? ใน Wikipedia ไม่ได้ลงรายละเอียดไว้ เจอที่นี่: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...

    • นี่เป็นหนึ่งใน เรื่องอื้อฉาว ที่เกี่ยวข้องกับซอฟต์แวร์ครั้งใหญ่ที่สุดในยุคของเรา
      อยากแนะนำให้ไปอ่านเพิ่ม แต่ต้องใจแข็งหน่อย หลายคนที่ขุดคุ้ยเรื่องนี้ถึงกับต้องมองหาถังไว้ใกล้ตัว เนื้อหาดูแล้วรับยากจริง ๆ
    • ผมคิดว่าปัญหาอาจไม่ใช่ตัวบั๊กเท่า ความไม่ใส่ใจ
      ระบบขนาดใหญ่แทบจะมีบั๊กเสมอระหว่างพัฒนา แต่โดยปกติก็จะถูกพบและแก้ไข ที่นี่บั๊กถูกพบแล้วแต่ไม่ได้ถูกแก้
    • สรุปคือ บัญชีแยกประเภทแบบกระจาย ที่จัดหาโดยบุคคลที่สามมีการซิงก์คลาดเคลื่อน ขณะที่มีสิทธิ์เข้าถึงแบบตรวจสอบย้อนหลังไม่ได้ และผู้จัดการสาขาถูกใช้เป็นแพะรับบาปในข้อหาฉ้อโกงที่ไม่มีอยู่จริง เพราะ “คอมพิวเตอร์บอกว่าเป็นอย่างนั้น”
  • สมมติฐานพื้นฐานของผมคือคอมพิวเตอร์ทำงานไม่ถูกต้อง
    เพราะในความเป็นจริงเห็นกรณีที่มันทำงานไม่ถูกต้องมามากเกินไป แม้แต่ตอนขับรถก็ไม่ได้เชื่อ Google Maps ตามนั้น แต่จะตรวจว่าทางที่แนะนำสมเหตุสมผลไหม และดูชื่อถนนกับหมายเลขทางออกตรงจุดที่ให้เลี้ยวอีกครั้ง โดนมาแล้วหลายครั้งเกินไป

  • จากประสบการณ์ในฐานะโปรแกรมเมอร์ ตัวคอมพิวเตอร์เองมักทำงานถูกต้อง
    แทบไม่เคยเป็นบั๊กของฮาร์ดแวร์ แต่ ซอฟต์แวร์ ผิดพลาดอยู่เสมอ และฮาร์ดแวร์คอมพิวเตอร์ก็แค่ทำตามสิ่งที่ซอฟต์แวร์สั่งอย่างมืดบอด

    • จากประสบการณ์ในฐานะโปรแกรมเมอร์ที่ทำงานกับไดรเวอร์ ฮาร์ดแวร์ แทบไม่เคยทำงานถูกต้อง
      ถึงขั้นที่ “แก้ในซอฟต์แวร์ก็ได้” น่าจะเป็นคำขวัญทางการของวงการฮาร์ดแวร์ได้เลย
    • การแบ่งแยกนั้นไม่เกี่ยวกับบทความนี้
      ในที่นี้ “คอมพิวเตอร์” หมายถึงระบบที่ประกอบด้วยฮาร์ดแวร์และซอฟต์แวร์ และคำว่า “คอมพิวเตอร์” ก็แทบจะถูกใช้ในความหมายนี้เสมอ ปัญหาคือศาลสันนิษฐานว่าคอมพิวเตอร์ทำงานปกติหากไม่มีหลักฐานโต้แย้ง กล่าวคือศาลอาจพอใจได้ว่าข้อเท็จจริงที่เกี่ยวข้องได้รับการพิสูจน์แล้วด้วยบันทึกจากคอมพิวเตอร์เพียงอย่างเดียว และหากจำเลยไม่สามารถแสดงให้เห็นว่าคอมพิวเตอร์ทำงานไม่ถูกต้อง ศาลก็จะยอมรับว่าหัวหน้าไปรษณีย์สาขามียอดเงินขาด สรุปคือถ้าแกนหลักของคดีอาญาคือบันทึกจากคอมพิวเตอร์ ก็เท่ากับว่า คอมพิวเตอร์บอกว่ามีความผิด
    • ในฮาร์ดแวร์มี พฤติกรรมเฉพาะแปลก ๆ หรือการแฮ็กเล็ก ๆ น้อย ๆ จำนวนมากเพื่อทำให้มันทำงานได้ถูกต้อง และในความเป็นจริงก็มักทำงานไม่ถูกต้อง
      ซอฟต์แวร์ที่แตะฮาร์ดแวร์โดยตรงในระดับต่ำมากมักถูกคาดหวังให้ชดเชยความขรุขระเหล่านี้
    • เรื่องนี้เกิดขึ้นกับฮาร์ดแวร์ด้วย
      ตัวอย่างเก่า ๆ คือ CPU Intel Pentium มีบั๊กโด่งดังสองตัวที่พบหลังวางจำหน่าย ได้แก่ บั๊ก FDIV ในการหารเลขทศนิยมลอยตัว ซึ่งนำไปสู่การเรียกคืนสินค้าในปี 1994 และบั๊ก F00F ที่พบในปี 1997 ซึ่งทำให้โปรเซสเซอร์หยุดทำงานจนกว่าจะรีบูต
      https://en.m.wikipedia.org/wiki/Hardware_bug
    • กำลังอธิบายประสบการณ์แบบเดียวกับที่คนที่ไม่ใช่โปรแกรมเมอร์เจอเมื่อมองซอฟต์แวร์
      คือเพราะมันมักจะทำงานได้ เลยมักถือว่าเป็นปัญหาของผู้ใช้แทบเสมอ ถ้าไม่รู้ว่าต้องมองหาอะไร ก็จะตัดทิ้งได้แค่กรณีข้อผิดพลาดที่รู้จัก แล้วนำไปสู่ การตัดสินผิดพลาด อันเลวร้ายเหมือนในบทความข้างต้น
  • ข้อสันนิษฐานนี้จะเป็นปัญหาเป็นหลักเมื่อผู้ดำเนินการคอมพิวเตอร์เป็นฝ่ายเดียวกับฝ่ายที่ไล่บี้ผู้อื่น

    1. คนนอกตรวจสอบการทำงานของคอมพิวเตอร์ได้ยากหรือเป็นไปไม่ได้ และ 2) ผู้ดำเนินการมีแรงจูงใจสูงที่จะบิดเบือนเอาต์พุตของคอมพิวเตอร์หรือปกปิดข้อผิดพลาด ในกรณีที่เกี่ยวข้องจากมุมตรงข้าม ผมนึกถึงเมื่อหลายปีก่อนที่พวก copyright troll ใช้ล็อกที่ตัวเองสร้างขึ้นจาก swarm ของ BitTorrent เป็นหลักฐานในศาล ข้อมูลแบบนี้ปลอมแปลงได้ง่ายมาก และคนนอกแทบตรวจจับไม่ได้ แถมยังมี แรงจูงใจทางการเงิน สูงที่จะทำแบบนั้นด้วย ข้อเท็จจริงที่ว่า “หลักฐาน” แบบนี้ถูกนำมาพิจารณาในศาลดูไร้สาระมาก
    • อา คดี Prenda Law ชวนให้นึกถึงอดีตเลย
  • แม้จะเป็นคำถามว่าศาลควรสันนิษฐานอะไร แต่ก็น่าถามเช่นกันว่านักพัฒนาซอฟต์แวร์สันนิษฐานหรือไม่สันนิษฐานอะไร
    นักพัฒนาซอฟต์แวร์น่าจะสันนิษฐานว่าซอฟต์แวร์ที่ใช้กันอย่างแพร่หลายนั้นทำงานถูกต้อง ต่อให้มีบั๊กใน GitHub issues ของ pandas อยู่ 3,500 รายการ ก็ยังถือว่า JavaSDK หรือ ไลบรารี pandas ทำงานถูกต้อง แต่ถ้ากำลังผสานไลบรารีที่ไม่ค่อยเป็นที่รู้จัก หรือใช้ซอฟต์แวร์ที่ไม่ค่อยเป็นที่รู้จัก ก็จะมั่นใจในการทำงานของมันน้อยลง

    • หากมีสายตามากพอ บั๊กทุกตัวก็จะตื้น
      ในความหมายที่ว่ามันจะทำให้คนหลายพันคนบ่นกันเป็นเวลาหลายปี ถ้าพูดแบบเหน็บแนมน้อยลง เราคาดหวังได้ว่าฟีเจอร์ที่ใช้กันแพร่หลายในซอฟต์แวร์ที่ใช้กันแพร่หลายผ่านการทดสอบในสภาพจริงมาแล้ว ดังนั้นแม้จะมีบั๊ก อย่างน้อยก็น่าจะเป็นที่รู้จัก แต่แค่ พื้นที่สถานะ ของซอฟต์แวร์ที่ซับซ้อนระดับกลางก็ยังต้องใช้การทดสอบมหาศาลเพื่อครอบคลุมทั้งหมด ดูได้จาก test suite ของ SQLite ว่าใหญ่แค่ไหน แนวทางเดียวที่ดูจะได้ผลดีในการสร้างซอฟต์แวร์ที่มีบั๊กน้อย คือการประกอบชิ้นส่วนที่เล็ก สมบูรณ์ในตัว แยกจากกัน และเข้าใจได้ดี เพื่อทำให้ภาพรวมให้เหตุผลได้ง่ายขึ้น นี่คือปรัชญาดั้งเดิมของ Unix เป็นปรัชญาของ functional programming และเป็นส่วนหนึ่งของปรัชญาระบบ actor ด้วย แม้การให้เหตุผลเกี่ยวกับปฏิสัมพันธ์แบบ asynchronous จะยากกว่าก็ตาม หวังว่าจะได้เห็นแนวทางนี้มากขึ้นเรื่อย ๆ ในงานจริง
  • ชื่อเรื่องอาจเกือบจะเป็นตรงข้ามของ clickbait
    บทความพูดถึงเรื่องอื้อฉาวของ Post Office และเป็นการจับ ประเด็นใหญ่ จริง ๆ

  • ลิงก์เก็บถาวร: https://archive.ph/wip/AJl8i