Wireshark ครบรอบ 25 ปี: อีเมลที่เป็นจุดเริ่มต้นทุกอย่างและบทเรียนที่ได้เรียนรู้

 (blog.wireshark.org)
1 คะแนน โดย GN⁺ 2023-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อีเมลเปิดตัว Ethereal 0.2.0 ที่ Gerald Combs ส่งเมื่อวันที่ 14 กรกฎาคม 1998 นำไปสู่ Wireshark ในอีก 25 ปีต่อมา และเครื่องมือส่วนตัวก็เติบโตเป็นโครงการโอเพนซอร์สอายุยืน
  • ในเวลานั้นโปรแกรมวิเคราะห์โปรโตคอลแบบ GUI มักเป็น ผลิตภัณฑ์เชิงพาณิชย์ราคาแพง ส่วนตัวเลือกฟรีมีเพียงเครื่องมือบรรทัดคำสั่งอย่าง tcpdump หรือ snoop จึงเปิดซอร์สโปรแกรมวิเคราะห์ที่สร้างขึ้นเอง
  • เพียงไม่กี่วันหลังเผยแพร่ก็มีแพตช์ส่งเข้ามาและเกิดชุมชนนักพัฒนา ทำให้ Wireshark ถูกนำไปใช้เพื่อปรับปรุง ประสิทธิภาพ·ความเชื่อถือได้·ความปลอดภัย ของเครือข่าย รวมถึงใช้ในการศึกษา
  • การดำเนินงานระยะยาวไม่ได้ต้องการแค่ผู้ใช้ ผู้สอน และนักพัฒนาเท่านั้น แต่ยังต้องมีการสนับสนุนด้านกฎหมาย บัญชี และโครงสร้างพื้นฐานด้วย และขอบเขตการสนับสนุนที่ต้องใช้ก็แตกต่างกันไปตามขนาดของโครงการ
  • Wireshark ซึ่งได้รับการสนับสนุนจาก CACE Technology, Riverbed และ Sysdig ได้ย้ายไปอยู่ภายใต้ Wireshark Foundation เมื่อไม่นานมานี้ เพื่อวางรากฐานสำหรับการเติบโตอย่างเป็นอิสระ

จากการเปิดตัว Ethereal สู่ 25 ปีของ Wireshark

  • เมื่อ 25 ปีก่อน Gerald Combs ได้ส่งอีเมลหัวข้อ ANNOUNCE: Ethereal 0.2.0
    • Ethereal เป็น โปรแกรมวิเคราะห์เครือข่าย ที่สามารถดักจับเนื้อหาของ Ethernet frame และสำรวจแบบโต้ตอบได้
    • ข้อมูลแพ็กเก็ตสามารถอ่านจากไฟล์หรืออ่านแบบเรียลไทม์จาก local network interface ได้
    • มีการแจกจ่ายซอร์สโค้ดพร้อมข้อมูลเพิ่มเติม และระบุว่ายินดีรับความคิดเห็นและแพตช์
  • ชื่อโครงการไม่ได้เป็น Wireshark มาตั้งแต่แรก และเปลี่ยนเป็น Wireshark ใน 2006
  • ในช่วงที่เปิดตัว โปรแกรมวิเคราะห์โปรโตคอลยังไม่ใช่สิ่งที่พบได้ทั่วไป และโปรแกรมวิเคราะห์แบบ GUI มักเป็นผลิตภัณฑ์ราคาแพง
    • หากต้องการตรวจสอบสถานะเครือข่าย ก็สามารถใช้เครื่องมือบรรทัดคำสั่งฟรีอย่าง tcpdump หรือ snoop ได้
    • แต่ถ้าต้องการโปรแกรมวิเคราะห์แบบ GUI ก็ต้องซื้อผลิตภัณฑ์เชิงพาณิชย์ราคาแพง
  • เพราะไม่มีโปรแกรมวิเคราะห์ที่ตอบโจทย์งานของตน Gerald Combs จึงสร้างเครื่องมือง่าย ๆ ขึ้นมาเองและเผยแพร่เป็น โอเพนซอร์ส

การเติบโตที่ชุมชนสร้างขึ้น

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

สิ่งที่โครงการโอเพนซอร์สที่ยืนยาวต้องมี

  • หากโครงการโอเพนซอร์สจะเติบโตและดำรงอยู่ได้ ก็ต้องตอบโจทย์ความต้องการหลายหมวดไปพร้อมกัน

  • การสนับสนุนผู้ใช้

    • ผู้ใช้งานจริงมีความหลากหลาย ตั้งแต่ผู้ใช้ประจำที่ชำนาญไปจนถึงผู้เริ่มต้น
    • บางครั้งผู้ใช้ต้องการความช่วยเหลือ และความช่วยเหลือที่ต้องการก็แตกต่างกัน

  • การสนับสนุนผู้สอน

    • ผู้เชี่ยวชาญและผู้ใช้ที่ชำนาญสามารถสอนให้ผู้อื่นใช้โครงการได้ดีขึ้น
    • ผู้สอนเองก็ต้องการการสนับสนุนอย่างต่อเนื่องเช่นกัน

  • การสนับสนุนนักพัฒนา

    • ยิ่งทำให้การมีส่วนร่วมกับโค้ดหรือการปรับปรุงโครงการทำได้ง่ายเท่าไร โครงการและชุมชนก็ยิ่งแข็งแรงขึ้นเท่านั้น

  • การสนับสนุนด้านกฎหมายและบัญชี

    • เรื่องกฎระเบียบ กฎหมาย และการเงิน เช่น กฎหมายทรัพย์สินทางปัญญา หรือการเบิกค่าเดินทาง จำเป็นต้องอาศัยความช่วยเหลือจากภายนอก
    • GitHub หรือ GitLab เพียงอย่างเดียวไม่สามารถจัดการเรื่องเหล่านี้ได้

  • โครงสร้างพื้นฐาน

    • ต้องมีเซิร์ฟเวอร์ คอนเทนเนอร์ และบริการที่ทำให้เกิดการทำงานร่วมกันและการมีตัวตนบนออนไลน์
    • GitHub หรือ GitLab จะเพียงพอหรือไม่นั้น ขึ้นอยู่กับความต้องการเฉพาะของแต่ละโครงการ

โครงสร้างการสนับสนุนที่เปลี่ยนไปตามขนาดโครงการ

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

โมเดลการดำเนินงานของ Wireshark และการย้ายไปสู่ Foundation

  • Wireshark เป็นโครงการที่ใกล้เคียงกับแอปพลิเคชันขนาดใหญ่ จึงต้องการการดูแลและการสนับสนุนจำนวนมาก
  • จนกระทั่งเมื่อไม่นานมานี้ ทรัพยากรที่จำเป็นได้มาจากการขอให้นายจ้างของ Gerald Combs เป็นผู้โฮสต์โครงการ
  • CACE Technology, Riverbed และ Sysdig ได้มอบทรัพยากรให้ Wireshark มากกว่าสิ่งที่ GitHub หรือ GitLab จัดให้ได้
    • ตัวอย่างเช่น SharkFest ซึ่งเป็นคอนเฟอเรนซ์เฉพาะด้านการวิเคราะห์โปรโตคอล
  • ในช่วงไม่กี่ปีที่ผ่านมา ความจำเป็นที่โครงการจะต้องยืนได้ด้วยตนเองเพิ่มสูงขึ้น และด้วยความช่วยเหลือจาก Sysdig โครงการจึงย้ายไปสู่ Wireshark Foundation เมื่อต้นปีนี้
  • การย้ายไปสู่ Foundation เป็นรากฐานที่ทำให้ Wireshark สามารถเติบโตต่อไปและสนับสนุนชุมชนได้

คำแนะนำที่ยังคงอยู่หลังผ่านไป 25 ปี

  • Gerald Combs บอกว่า ตอนที่ส่งอีเมลเมื่อ 25 ปีก่อน เขาไม่เคยคิดว่าวันนี้จะได้มาเขียนบล็อกเกี่ยวกับโครงการนี้
  • ประสบการณ์จากการสนับสนุนและดูแล Wireshark มอบทั้งเส้นทางอาชีพที่ยอดเยี่ยม และโอกาสได้พบผู้คนเก่ง ๆ เพื่อร่วมงานกัน
  • เขาฝากข้อความว่าหากอยากเริ่มโครงการโอเพนซอร์ส ก็อย่าลังเล
  • สิ่งสำคัญคือการทำให้ชุมชนสามารถแบ่งปัน มุมมองที่มีคุณค่า ของตนได้
  • หากไม่กลัวที่จะเริ่มต้นสิ่งใหม่ ก็ไม่มีทางรู้ได้เลยว่าอีก 25 ปีข้างหน้าจะไปถึงจุดไหน

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2023-07-16
ความคิดเห็นจาก Hacker News

  • Wireshark เป็นเหมือนค้อนในสุภาษิตที่ทำให้ทุกปัญหาเครือข่ายดูเหมือนตะปู
    ต่อให้มีเครื่องมือที่เฉพาะทางกว่า ถ้าหยิบ Wireshark เข้าใส่ก็มักจะหาสาเหตุเจอได้
    ยังน่าแปลกใจอยู่เสมอว่ามีคนมากแค่ไหนที่เรียกตัวเองว่าผู้เชี่ยวชาญด้านเครือข่ายแต่ไม่เคยใช้หรือไม่เข้าใจ Wireshark ทั้งที่มันอาจเป็นเครื่องมือสำคัญที่สุดในการทำความเข้าใจว่าเกิดอะไรขึ้นจริงบนเครือข่าย
    เมื่อวานนี้เองก็เพิ่งตามรอยอาการผิดปกติของระบบ Asterisk/FreePBX ที่อัปเกรดแล้วด้วยการจับแพ็กเก็ต ถ้าไม่มีมันคงได้แต่เดาอยู่หลายวัน แต่พอดูสิ่งที่เกิดขึ้นบนเครือข่ายก็จำกัดวงปัญหาได้ทันที

    • มันเหมือน ดีบักเกอร์ สำหรับงานเครือข่าย และน่าแปลกที่แม้แต่ในหมู่นักเขียนโปรแกรมก็ยังมีหลายคนที่ใช้ดีบักเกอร์ไม่เป็น
    • อยากรู้ว่ามีแหล่งข้อมูลดีๆ สำหรับทำความเข้าใจ Wireshark แบบจริงจังไหม
      ไม่ใช่ผู้เชี่ยวชาญด้านเครือข่าย แต่เคยใช้บ้างเป็นครั้งคราวเพราะเกี่ยวกับงาน และรู้สึกได้ถึงพลังของมัน ทว่าเมื่อเริ่มต้นโดยไม่ได้มีปัญหาเล็กๆ ที่เฉพาะเจาะจงมาก มันเป็นเครื่องมือที่ชวนให้ล้นมือ
      เลยสงสัยว่ามันเป็นเครื่องมือประเภทที่ค่อยเรียนรู้ไปตามเวลาที่ต้องใช้หรือเปล่า
    • ถ้ามีเวลา อยากให้ช่วยเล่าว่าปัญหา Asterisk/FreePBX นั้นคืออะไร และแก้ได้อย่างไรด้วย การจับแพ็กเก็ต
      น่าจะเป็นบล็อกโพสต์ที่น่าสนใจมาก
    • Wireshark ช่วยได้มากแม้ในงานที่ไม่ได้เฉพาะทางและหนักลึกแบบเครือข่าย
      ราวปี 2013 ที่ Amazon ต้องทำแอป/บริการ Spring/Java แบบเลกาซีเป็นต้นแบบแนวคิดด้วย Node.js ภายในหนึ่งสัปดาห์ และมีทั้งการยืนยันตัวตนระหว่างบริการกับระบบส่งข้อความ Tibco ที่พัวพันกันอยู่
      หาการติดตั้งไคลเอนต์ Tibco แบบสาธารณะไม่เจอ และด้วยหลักการผู้นำที่เน้นความประหยัด ก็แทบเป็นไปไม่ได้ที่จะได้สเปกทางการ แต่จริงๆ ต้องการแค่รายละเอียดโครงสร้างแพ็กเก็ตของบางคำขอเท่านั้น
      เดาได้เลยว่าเครื่องมืออะไรช่วยชีวิตไว้ และตอนนั้นแม้แต่ Principal Engineer ก็ยังแปลกใจว่ามีเครื่องมือแบบนี้อยู่ด้วย

  • ปี 1983 ตอนที่ Ethernet ยังใช้ สายโคแอกเชียลเส้นหนา กับ vampire tap อยู่ ได้ทำงานที่บริษัทรับเหมาด้านกลาโหมใน Silicon Valley
    เราสร้างผลิตภัณฑ์ Ethernet bridge ที่เชื่อม DECnet LAN ของสถานีภาคพื้น DSCS (Defense Satellite Communications System) ทั่วโลกผ่านลิงก์เข้ารหัส 9600bps และได้เขียนตัวดัมป์แพ็กเก็ตที่ตั้งการ์ด Ethernet เป็น promiscuous mode เป็นส่วนหนึ่งของโค้ด
    ตอนนั้นยังไม่มีตัวแปลความแบบ Wireshark แต่แค่สามารถดัมป์แพ็กเก็ตดิบเป็นเลขฐานสิบหกลงเทอร์มินัลได้ก็เป็นข้อได้เปรียบมหาศาลสำหรับการดีบักเครือข่ายแล้ว
    เวลาไปติดตั้งระบบใหม่ Wireshark เป็นหนึ่งในเครื่องมือแรกๆ ที่จะติดตั้งเสมอ

    • อยากรู้ว่า Ethernet เปลี่ยนผ่านจากสายเส้นหนากับ vampire tap ไปเป็น RJ45 ได้อย่างไร
      ไม่แน่ใจว่ามันยังเป็นโปรโตคอลเดียวกันเป๊ะไหมทั้งในตอนนั้นและตอนนี้ หรือคำว่าโปรโตคอลนี่ถูกต้องหรือเปล่า
      ทำให้อยากลงลึกเรื่องเครือข่ายมากขึ้น

  • ผมคือคนที่สร้าง Wireshark
    ตื่นเช้ามาแล้วรู้สึกดีมากที่ได้เห็นคำพูดอบอุ่นและความทรงจำจากทุกคน

    • ตลอดหลายปีที่ผ่านมาใช้ Wireshark แก้ปัญหาไปมาก แต่ช่วงนี้แทบไม่ได้ใช้แล้ว เพราะดูเหมือนมันตาม อัตราการส่งข้อมูล ที่พบทั่วไปบนเซิร์ฟเวอร์สมัยนี้ไม่ทัน
      การวิเคราะห์เหมือนจะเป็นเธรดเดียวและดูไม่มีแคช จนแม้แต่ไฟล์จับข้อมูลขนาดไม่กี่ GB ซึ่งเป็นข้อมูลเพียงไม่กี่วินาทีบนลิงก์ 10Gbps ก็ยังรับมือได้ลำบาก

  • มันเป็นเครื่องมือที่ขาดไม่ได้ในการทำงานของผมมาตั้งแต่แรก
    tcpdump ก็ใช้ได้ดี แต่การคลิกขวาที่แพ็กเก็ตแล้วเลือก follow TCP stream เพื่อดูบทสนทนาทั้งหมดได้ภายใน 1 วินาทีนั้นเป็นฟีเจอร์ที่เปลี่ยนเกมจริงๆ
    เช่นเดียวกับ “right click->filter out this stream” และเพราะ Ethereal/Wireshark อ่านไฟล์ที่ tcpdump บันทึกได้ จึงสามารถ ssh เข้าเซิร์ฟเวอร์ระยะไกลเพื่อรัน tcpdump แล้วใช้ Wireshark บนไคลเอนต์ตรวจสอบสตรีมเครือข่ายทั้งสองฝั่งได้
    NAT แปลกๆ ของ ISP มองเห็นได้ในพริบตา และเครือข่าย MPLS ที่ตั้งค่าผิดก็สามารถนำมาเป็นหลักฐานได้ ทำให้ทีม routing ไม่สามารถพูดแค่ว่า “ฝั่งเราดูปกติดี”
    แต่อยากแก้ไขอยู่เรื่องหนึ่งในบทความ Ethereal ไม่ใช่โปรแกรมวิเคราะห์แพ็กเก็ตเครือข่ายแบบ GUI ฟรีตัวแรก เพราะตั้งแต่ยุค Windows NT ก็มีเครื่องมืออย่าง netmon ของ Microsoft แล้ว

    • เครื่องมือนั้นคือ Network Monitor หรือ netmon และภายในก็เรียกว่า Bloodhound ด้วย
      มันมี API ที่มีเอกสารด้วย และแม้สถานะการซัพพอร์ตจะคลุมเครือ แต่ใช้งานต่อได้ง่ายจนเคยทำ tcpdump wrapper บนมันก่อนยุค Ethereal
      พอ “next-generation” TCP stack ของ Longhorn/Vista ออกมา API นั้นกับ netmon ก็ใช้การไม่ได้
      หลังจากนั้นมี Microsoft Message Analyzer ออกมา ซึ่งใช้ ETW เป็นฐานเพื่อวิเคราะห์ทั้งเครือข่ายและ ETW trace อื่นๆ และยังมี DSL ที่รองรับการเขียน protocol handler แบบใดก็ได้
      มันยังทำให้พาร์เซไฟล์ล็อกและกรอง/วิเคราะห์ข้อมูลได้ด้วย ทรงพลังมากและมีประโยชน์กับนักพัฒนา Windows มากเสียจนสุดท้าย Microsoft ก็ยกเลิกมันไป
    • ถ้ามันทำงานได้เฉพาะบน Windows ก็ยังตอบยากว่ามัน “ฟรี” จริงไหม
      ท้ายที่สุดก็เป็นเครื่องมือที่รวมมากับระบบปฏิบัติการที่ต้องจ่ายเงินซื้ออยู่ดี

  • Wireshark ก็เหมือน มัลติมิเตอร์ ของวงการอิเล็กทรอนิกส์
    ไม่มีมันโลกก็ยังหมุนต่อไปได้ แต่ถ้ามีอะไรเสียขึ้นมาแล้วไม่มีมันก็แย่แน่

    • Wireshark กับ tcpdump ช่วยให้ผมหาปัญหาแปลกๆ ในเครือข่ายมหาวิทยาลัยเจอได้เยอะมาก

  • เครื่องมือนี้ซึ่งตอนนั้นยังชื่อ Ethereal มีค่ามากจริงๆ ตอนทำงานเป็น Senior Tech Support ให้ชุดผลิตภัณฑ์ WebLogic
    มันทำให้สามารถให้ลูกค้ารันเองแล้วตอบกลับไปได้ว่า “ทุกการเชื่อมต่อใน พูลการเชื่อมต่อ JDBC ขนาดใหญ่ถูกไฟร์วอลล์เครือข่ายที่ลูกค้าเองก็ไม่รู้ว่ามี ตัดทิ้งแบบเงียบๆ และนั่นทำให้ทรานแซกชันแรกของตอนเช้าช้าไป 1 ชั่วโมง ต้องรอให้ทุกการเชื่อมต่อในพูลหมดเวลาแล้วรีเซ็ตใหม่”
    และยังจับปัญหาอย่าง “Internet Explorer ตัดการเชื่อมต่อ TCP ของทรัพยากรที่แคชไว้แล้ว จนทำให้เกิดข้อผิดพลาดระดับเครือข่ายที่ไม่เป็นมาตรฐานบนการติดตั้ง WebLogic ของเซิร์ฟเวอร์ IBM” ได้ด้วย
    งานนั้นทำให้ผมผมร่วงไปครึ่งหัว แต่ถ้าไม่มี Ethereal คงเสียไปหมดทั้งหัวและเสียสติหนักกว่านี้มาก

  • ผมซัพพอร์ต โหลดบาลานเซอร์ ในเครือข่ายลูกค้ามานานกว่าสิบปีและใช้ Wireshark ทุกวัน
    pcap กับ core dump เป็นข้อมูลที่น่าสนใจที่สุดในการทำงาน ได้เรียนรู้ libpcap และสุดท้ายถึงขั้นทำเวอร์ชันของตัวเองขึ้นมา จนย้ายจากฝ่ายซัพพอร์ตผลิตภัณฑ์ไปสู่ฝ่ายพัฒนาได้
    เข้าไปในฐานะวิศวกรซัพพอร์ต แล้วออกมาเป็น Principal Software Engineer ที่เขียนโค้ดซึ่งตัวเองเคยต้องซัพพอร์ต และด้วย Wireshark กับ gdb ก็ทำให้ผมเรียนรู้ด้วยตัวเองได้มากมายโดยไม่ต้องเข้ามหาวิทยาลัย

    • ผมชอบเรียกมันว่าปัญหาแบบ “ไม่รู้ว่าอะไรผิด แต่ต้องเป็นปัญหาเครือข่ายแน่ๆ”

  • เป็นเครื่องมือที่ยอดเยี่ยมจริงๆ และ ฟรีอย่างแท้จริง
    ใช้มันบ่อยเวลาต้องดีบักปัญหาเครือข่ายและดูว่าอุปกรณ์เชื่อมต่อไปที่ไหน และอย่างที่มีคนบอก มันเหมือนมัลติมิเตอร์สำหรับเครือข่าย
    เคยใช้มันเพื่อเรียนรู้การตั้งค่าการเชื่อมต่อกับจุดเชื่อมต่อ WiFi และสามารถเห็นทั้งแพ็กเก็ต beacon และแพ็กเก็ต WiFi อื่นๆ ได้

    • ผมใช้ Ethereal ตั้งแต่ช่วงแรกมากๆ
      ทีมมี Sniffer PC อยู่ แต่บ่อยครั้งมันถูกคนอื่นใช้อยู่ หรือการแปลความโปรโตคอลก็ยังไม่ดีพอ

  • เป็นซอฟต์แวร์ที่ยอดเยี่ยมจริงๆ
    เมื่อ 20 ปีก่อนเคยติดอยู่ที่ไซต์ของลูกค้าเพราะพยายามหาปัญหาความเข้ากันได้ของอุปกรณ์เครือข่ายของเรา และจำได้ว่าใช้เวลา 2 สัปดาห์เขียน ปลั๊กอินตัวแปลความโปรโตคอล แล้วมันช่วยได้ค่อนข้างง่าย
    สุดท้ายแล้วเป็นบั๊กของเราเอง เกิดจากตอนเปลี่ยนการติดตั้งจาก select() ไปเป็น epoll() แล้วไม่ได้เอาการใช้บิตแมสก์สำหรับ select() ออก
    โดยเนื้อแท้แล้วมันคือข้อผิดพลาดหน่วยความจำเสียหาย 1 บิต และผลลัพธ์อาจแสดงออกช้ามาก
    แปลกดีที่เรื่องแบบนี้กลับจำได้นาน

    • อิจฉาความสามารถในการหาความสนุกจากเรื่องแบบนี้
      ช่วงต้นอาชีพเคยอยู่ในสถานที่ปลอดภัยที่ไม่อนุญาตให้ติดตั้ง wireshark เลยต้องขุดบั๊กเครือข่ายชวนหงุดหงิดด้วย tcpdump อย่างเดียวอยู่หนึ่งสัปดาห์
      สุดท้ายพบว่าเป็นปัญหาที่เกิดจากการรวมกันของบั๊กร้ายแรงที่สุดใน standard library ของ GNAT เมื่อ 10 ปีก่อน (ไลบรารี Ada) กับการตั้งค่า ARP ผิดพลาด และจริงๆ แล้วบั๊กในไลบรารีนั้นถูกแก้ไปตั้งแต่ 7 ปีก่อนแล้ว
      สัปดาห์นั้นเลวร้ายมากจนมีผลอย่างมากต่อการตัดสินใจย้ายไปที่ที่ดีกว่า และการจะสนุกกับเรื่องแบบนี้ได้ต้องเป็นคนประเภทพิเศษจริงๆ

  • ผู้คนมักจินตนาการถึงการเปลี่ยนโลก แต่ก็มี คนที่เปลี่ยนโลกจริงๆ อยู่ด้วย